Questioning systemd tmpfiles.d packaging guidelines

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Questioning systemd tmpfiles.d packaging guidelines

Thorsten Kukuk

Hi,

background: with Richards move of the rpm db to /usr, we are now
looking at and cleaning up the content and subvolume mess in /var.
And, if you take snapshots, rollback and transactional-updates serious,
not everything in /var is accessible during upgrade.
A solution for some of the problems is tmpfiles.d.

So I converted two packages as PoC to use tmpfiles.d, and it works fine,
except that rpmlint now reports a lot of policy violations. And I'm
questioning, if this checks are really correct or what the idea behind
this was.

So my problems:

1. We call systemd-tmpfiles with the full path to the tmpfiles
   configuration. And this is documented in this way in our wiki, too.
   But: if I read the manual page correct, this is the wrong way. If
   you specify the full path to the config file as argument, adjusted
   configuration files in /etc done by the sysadmin are ignored.
   Why do we force every packager to ignore changes made by the admin
   here?

2. We tell the packager to add %ghost entries for every file, so that
   rpm -qf works. I can understand the reason, but in my experience,
   this %ghost entries always create problems later during update or
   deinstallation. Additional, rpm tries to mess around with this files
   during update/de-installation, but not always this files are accessible
   at this time. And if I can add the files to the package list, in most
   cases I don't need tmpfiles.d, but could add them directly to the
   file list.
   My dream: rpm -qf is looking at tmpfiles.d, if it does not find the
   file in the RPM database. Knowing that tmpfiles is creating this
   file and which configuration file is much, much more helpfull!

I would like to see at least the full path to the configuration file
changed to only the name of the configuration file. And maybe somebody
has a better idea how to track tmpfiles.d config file changes except
%ghost entries in RPM.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Questioning systemd tmpfiles.d packaging guidelines

Thorsten Kukuk
On Thu, Nov 09, Franck Bui wrote:

> On 11/08/2017 09:44 AM, Thorsten Kukuk wrote:
> >
> > So my problems:
> >
> > 1. We call systemd-tmpfiles with the full path to the tmpfiles
> >    configuration. And this is documented in this way in our wiki, too.
> >    But: if I read the manual page correct, this is the wrong way. If
> >    you specify the full path to the config file as argument, adjusted
> >    configuration files in /etc done by the sysadmin are ignored.
> >    Why do we force every packager to ignore changes made by the admin
> >    here?
>
> I must admit that I can't think of a useful case where the admin would
> need to overwrite the tmpfiles shipped by a package. You seem to have
> found a case but unfortunately you haven't provided any details on it so
> it's hard to tell.

I don't have a specific case, I did only read the manual page and found
a mismatch with what we are doing. Since the systemd manual pages and other
Distributions like Fedora explicit mention that you can overwrite the
tmpfiles, we should not "forbid" that for no good reason.

But if I look at read-only root filesystem, transactional-updates
and clusters, I can imagine some situations, where it could be quite
handy if you have the possibility to overwrite tmpfiles.

  Thorsten

> OTOH since tmpfiles can be overwritten, there're probably some cases
> where it makes sense. If so we shouldn't use and advice to use absolute
> paths indeed.

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]