[systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.

[Gustavo Sverzut Barbieri]

On Tue, Sep 30, 2014 at 04:26:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Sep 25, 2014 at 06:12:50PM -0300, Gustavo Sverzut Barbieri wrote:
> > etc.conf was selectively (using m4) using resolved link, now this is
> > moved to systemd-resolved.conf file. The etc.conf can be static and
> > does not need to be generated anymore.
> >
> > systemd.conf was doing all the journal setup, now this is moved to
> > systemd-journald.conf file.
> Is this useful? We don't support journald-less setups.
>
> > systemd-remote.conf was renamed to systemd-journal-remote.conf for
> > conssitency.
> This doesn't feel right either. systemd-remote.conf is not only
> for systemd-journal-remote, but also for systemd-journal-upload
> and systemd-journal-gateway, so the rename would be misleading.
> Current name is also the same as the name of the directory (src/journal-remote),
> so even if not perfect, it is not accidental.

I understand that, this is why I did the rename as people adding new
stuff only for upload would remember to create a new file.

my idea with split files for upload/remote is that they are vastly
different use cases and dependencies. Take an embedded system, it may
use upload to keep pushing crashes to manufacturer, takes only
curl. OTOH it does not need libmicrohttpd/gnutls to provide remote,
that is to be used on their server.

of course providing some tmpfiles/sysusers that are not used are not
that harmful, BUT to create the split packages they will get in the
way, as the file would be needed by both packages, this would need the
creation of yet-another package that would be required by both :-/


> > systemd.conf was doing all the networkd setup, now this is moved to
> > systemd-networkd.conf file.
> This part probably makes the most sense, since networkd is largely
> a separate beast.
>
> Those filenames form a kind of an interface, since they are overriden
> by name, so we shouldn't change them lightly.
>
> Can you respin the patch with just the networkd change?

well, I still hope you consider as per above explanations.

if not, could you do it for me? I'm going on vacation with limited
connectivity and no PC, fixing the patch from a tablet using some
remote build/test will be a PITA :-D otherwise I'm back in 15 days.

--
Gustavo Sverzut Barbieri
Intel Open source Technology Center