directories not owned by a package:

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

directories not owned by a package:

Christian
Hi,

don't think it is a good idea to have several packages owning 'same'
directory, isn't it ?

ovhpc-01:/usr/lib/tmpfiles.d # rpm -q --whatprovides $(pwd)
dmraid-1.0.0.rc16-34.3.x86_64
clamav-0.99.2-25.1.x86_64
amavisd-new-2.8.1-11.1.x86_64
screen-4.0.4-21.2.x86_64
lvm2-2.02.120-72.8.x86_64
dirmngr-1.1.1-10.1.x86_64
systemd-228-135.1.x86_64

which one is the correct one ?
and how to fix build error:
[   26s] xyzserver-1.67-0.x86_64.rpm: directories not owned by a package:
[   26s]  - /usr/lib/tmpfiles.d

without using...
%dir %{_prefix}/lib/tmpfiles.d

...and producing a further package providing same DIR.

Cheers
--

Christian
------------------------------------------------------------
   https://join.worldcommunitygrid.org?recruiterId=177038
------------------------------------------------------------
           http://www.sc24.de - Sportbekleidung
------------------------------------------------------------
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Olaf Hering-2
Am Tue, 28 Mar 2017 15:32:35 +0200
schrieb Christian <[hidden email]>:

> 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.

Olaf

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

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

>Am Tue, 28 Mar 2017 15:32:35 +0200
>schrieb Christian <[hidden email]>:
>
>> 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).
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Olaf Hering-2
Am Tue, 28 Mar 2017 15:55:31 +0200 (CEST)
schrieb Jan Engelhardt <[hidden email]>:

> On Tuesday 2017-03-28 15:43, Olaf Hering wrote:
>
> >Am Tue, 28 Mar 2017 15:32:35 +0200
> >schrieb Christian <[hidden email]>:
> >> 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

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Jan Engelhardt-4

On Tuesday 2017-03-28 16:00, Olaf Hering wrote:
>> On Tuesday 2017-03-28 15:43, Olaf Hering wrote:
>>
>> >Am Tue, 28 Mar 2017 15:32:35 +0200
>> >schrieb Christian <[hidden email]>:
>> >> 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.

/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.

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.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Olaf Hering-2
Am Tue, 28 Mar 2017 16:06:16 +0200 (CEST)
schrieb Jan Engelhardt <[hidden email]>:

> /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

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Jan Engelhardt-4
On Tuesday 2017-03-28 16:13, Olaf Hering wrote:

>Am Tue, 28 Mar 2017 16:06:16 +0200 (CEST)
>schrieb Jan Engelhardt <[hidden email]>:
>
>> /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?

Well yes the files are essentially unused. But the least thing you want to do
is split all tmpfiles out into even more separate subpackages.

(Also, when not running an system process manager in a namespace, the parent
namespace is usually responsible for initialization and tear-down of /dev and
/tmp.)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Brüns, Stefan
In reply to this post by Olaf Hering-2
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 <[hidden email]>:
> > /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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Thorsten Kukuk
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 ...

  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: directories not owned by a package:

Richard Biener
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 <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Johannes Meixner

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...


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)
Reply | Threaded
Open this post in threaded view
|

Re: directories not owned by a package:

Richard Biener
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 <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)