Am Tue, 28 Mar 2017 15:55:31 +0200 (CEST) schrieb Jan Engelhardt :

On Tuesday 2017-03-28 15:43, Olaf Hering wrote:

...

Am Tue, 28 Mar 2017 15:32:35 +0200 schrieb Christian :

...

don't think it is a good idea to have several packages owning 'same' directory, isn't it ? It is perfectly fine to own directories, module the ones which will be rejected because they are in filesystem.rpm. Yes, and /usr/lib/tmpfiles.d *IS* in filesystem (on TW).

Really? A thing that is apparently part of systemd shouldn't be in filesystem.rpm. Hopefully this was a well-thought decision. Olaf

Am Tue, 28 Mar 2017 16:06:16 +0200 (CEST) schrieb Jan Engelhardt :

/usr/lib/tmpfiles.d is a directory so prominently used that you do not want to repeat the line in every spec if possible. So you put it in a prominent package instead.

There are other similar prominent directories.

Second, container installations (chroot) may have no init system at all installed in them (because of minimalism), so to satisfy the prior desire, the directory has landed in filesystem.rpm instead.

Ah, but these containers have pkgs with tmpfiles but nothing processes them? Whatever ... Olaf

On Dienstag, 28. März 2017 16:13:59 CEST Olaf Hering wrote:

Am Tue, 28 Mar 2017 16:06:16 +0200 (CEST)

schrieb Jan Engelhardt :

...

/usr/lib/tmpfiles.d is a directory so prominently used that you do not want to repeat the line in every spec if possible. So you put it in a prominent package instead.

There are other similar prominent directories.

Yes. For example /etc/cron.{d,daily,hourly,monthly,weekly}, which are all owned by filesystem.

...

Second, container installations (chroot) may have no init system at all installed in them (because of minimalism), so to satisfy the prior desire, the directory has landed in filesystem.rpm instead.

Ah, but these containers have pkgs with tmpfiles but nothing processes them? Whatever ...

Of course running a weekly cleanup is absolutely required for a container having a lifetime of 10 minutes ... Regards, Stefan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 28 Mar 2017, Thorsten Kukuk wrote:

On Tue, Mar 28, Brüns, Stefan wrote:

...

Yes. For example /etc/cron.{d,daily,hourly,monthly,weekly}, which are all owned by filesystem.

They should be owned by cron, so that they are not there if there is no cron daemon and, RPMs shipping cron files, require cron so that they can be executed ...

Or rather RPMs that have cron files should ship configuration (cron files) separately from their main feature and the cron files package should supplement cron? I've never understood why we so closely tie default configuration with package requirements so you can't install some packages without dependencies you are never going to use (because you choose a different leaner configuration). IMHO dependencies tied to (default) configuration should come with a flavor package providing the (default) configuration. Pie in the sky... Richard.

Thorsten

-- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

On Wed, 29 Mar 2017, Johannes Meixner wrote:

Hello,

only addenda FYI:

On Mar 29 09:21 Richard Biener wrote:

...

On Tue, 28 Mar 2017, Thorsten Kukuk wrote:

...

On Tue, Mar 28, Brüns, Stefan wrote:

...

For example /etc/cron.{d,daily,hourly,monthly,weekly}, which are all owned by filesystem.

They should be owned by cron, so that they are not there if there is no cron daemon and, RPMs shipping cron files, require cron so that they can be executed ...

Cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1025689 "Move /etc/cups from the filesystem RPM into the cups-libs RPM"

...

Or rather RPMs that have cron files should ship configuration (cron files) separately from their main feature and the cron files package should supplement cron?

I've never understood why we so closely tie default configuration with package requirements so you can't install some packages without dependencies you are never going to use (because you choose a different leaner configuration). IMHO dependencies tied to (default) configuration should come with a flavor package providing the (default) configuration.

Cf. my "Explanation and reasoning" in https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c19

...

Pie in the sky...

...pretty please with a cherry on top...

;) In the past I was running into this when trying to minimize an installed system and I was surprised how many non-essential components we install when you just install aaa_base (and its dependencies). That was more than 5 years ago so things will probably have changed (to the worse I expect). Richard. -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)