curious about weirdness in some FILES_${PN} settings

curious about weirdness in some FILES_${PN} settings

[Robert P. J. Day]

  (warning: i've just been handed an existing OE code base, and i'm
going to ask some questions about some head-scratching things i'm
finding in it, so be prepared for weird questions.)

  in one recipe, i see the following snippet:

  FILES_${PN} += "/etc"
  FILES_${PN} += "/etc/mosquitto"
  FILES_${PN} += "/etc/mosquitto/config"
  ... etc etc ...

first, i'm taken aback by the hardcoding of "/etc" rather than using,
you know, "${sysconfdir}", so i'm *assuming* that unless someone was
doing something spectacularly clever here, that just can't be right.

  more to the point, the above seems redundant -- once you've added
"/etc", isn't the rest just superfluous? i'm not sure what the
original developer was going for here. thoughts?

  finally, if i wanted to add all of some directory, say "dir", it was
my understanding that all of the following were equivalent (hmmmm,
short of picking up hidden files, i guess):

  dir
  dir/
  dir/*

my personal preference would be "dir/", as it gets across the idea
that "dir" is a directory and i want all of it. thoughts on that as
well? i'm currently perusing the OE code base to see the general
consensus on this. is there one?

  more decidedly strange questions coming shortly ...

rday

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

[Andre McCurdy]

On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>   (warning: i've just been handed an existing OE code base, and i'm
> going to ask some questions about some head-scratching things i'm
> finding in it, so be prepared for weird questions.)
>
>   in one recipe, i see the following snippet:
>
>   FILES_${PN} += "/etc"
>   FILES_${PN} += "/etc/mosquitto"
>   FILES_${PN} += "/etc/mosquitto/config"
>   ... etc etc ...
>
> first, i'm taken aback by the hardcoding of "/etc" rather than using,
> you know, "${sysconfdir}", so i'm *assuming* that unless someone was
> doing something spectacularly clever here, that just can't be right.

Nothing clever going on, it's just a bug. In general, using /etc
instead of ${sysconfdir} etc will appear to work fine until you add
BBCLASSEXTEND and try to build <recipe>-native, at which point things
will start to fail in mysterious ways (since native.bbclass over-rides
the default values of ${sysconfdir} etc).

In this particular case, you might still get away with it since
FILES_${PN} is related to packaging and -native recipes don't do any
packaging but it's still not right.

>   more to the point, the above seems redundant -- once you've added
> "/etc", isn't the rest just superfluous? i'm not sure what the
> original developer was going for here. thoughts?

Yes, and even beyond that, ${sysconfdir} is handled by the default
packaging rules, so any extra packaging rules related to adding files
from /etc to the default package are redundant.

>   finally, if i wanted to add all of some directory, say "dir", it was
> my understanding that all of the following were equivalent (hmmmm,
> short of picking up hidden files, i guess):
>
>   dir
>   dir/
>   dir/*
>
> my personal preference would be "dir/", as it gets across the idea
> that "dir" is a directory and i want all of it. thoughts on that as
> well? i'm currently perusing the OE code base to see the general
> consensus on this. is there one?

That's more a question of coding style, which the OE maintainers etc
generally doesn't care about very much (unless you start asking about
unifying oe-core and meta-oe with respect to indenting with tabs or
spaces...).

>   more decidedly strange questions coming shortly ...
>
> rday
>
>
> 
>

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

[Robert P. J. Day]

... snipping some stuff ...

On Mon, 22 Mar 2021, Andre McCurdy wrote:

> On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >   in one recipe, i see the following snippet:
> >
> >   FILES_${PN} += "/etc"
> >   FILES_${PN} += "/etc/mosquitto"
> >   FILES_${PN} += "/etc/mosquitto/config"
> >   ... etc etc ...

... snip ...

> Yes, and even beyond that, ${sysconfdir} is handled by the default
> packaging rules, so any extra packaging rules related to adding
> files from /etc to the default package are redundant.

  actually, i neglected to mention that, just before all that FILES
assignment, the recipe totally redefined the PACKAGES variable, so
even the standard packaging rules had been thrown out the window and
replaced in their entirety.

  that will be another of my "please don't do stuff like that" list i
am working on.

rday

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

[Damian Wrobel]

 ---- On Mon, 22 Mar 2021 20:27:42 +0100 Andre McCurdy <armccurdy@gmail.com> wrote ----
 > On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
 > >   (warning: i've just been handed an existing OE code base, and i'm
 > > going to ask some questions about some head-scratching things i'm
 > > finding in it, so be prepared for weird questions.)
 > >
 > >   in one recipe, i see the following snippet:
 > >
 > >   FILES_${PN} += "/etc"
 > >   FILES_${PN} += "/etc/mosquitto"
 > >   FILES_${PN} += "/etc/mosquitto/config"
 > >   ... etc etc ...
 > >
 > > first, i'm taken aback by the hardcoding of "/etc" rather than using,
 > > you know, "${sysconfdir}", so i'm *assuming* that unless someone was
 > > doing something spectacularly clever here, that just can't be right.
 > 
 > Nothing clever going on, it's just a bug. In general, using /etc
 > instead of ${sysconfdir} etc will appear to work fine until you add
 > BBCLASSEXTEND and try to build <recipe>-native, at which point things
 > will start to fail in mysterious ways (since native.bbclass over-rides
 > the default values of ${sysconfdir} etc).
 > 
 > In this particular case, you might still get away with it since
 > FILES_${PN} is related to packaging and -native recipes don't do any
 > packaging but it's still not right.
 > 
 > >   more to the point, the above seems redundant -- once you've added
 > > "/etc", isn't the rest just superfluous? i'm not sure what the
 > > original developer was going for here. thoughts?
 > 
 > Yes, and even beyond that, ${sysconfdir} is handled by the default
 > packaging rules, so any extra packaging rules related to adding files
 > from /etc to the default package are redundant.
 > 
 > >   finally, if i wanted to add all of some directory, say "dir", it was
 > > my understanding that all of the following were equivalent (hmmmm,
 > > short of picking up hidden files, i guess):
 > >
 > >   dir
 > >   dir/
 > >   dir/*
 > >

Normally in the RPM world it matters if you gonna own a directory with all files in it
or just the directory or the file inside the directory but not the directory itself.
You can read more about it in  Fedora packaging guidelines "Unowned Directories"[1].

However, I'm not sure how this is implemented in yocto/bitbake if at all, as I couldn't find any
similar recommendation in [2]. You can always check who owns what using rpm tools like rpmls, rpm -qlv

Here is the real example from Fedora where the directory is owned by different package then
files inside a folder:

$ rpm -qf /etc/sysconfig/
filesystem-3.14-2.fc32.x86_64

$ rpm -qf /etc/sysconfig/atd
at-3.1.23-4.fc32.x86_64

This means that 'at' package doesn't need to create '/etc/sysconfig' directory and conversely removal of the
'at' package will not remove the '/etc/sysconfig' directory even if it was empty.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
[2] https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-FILES

--
Regards,
Damian


 > > my personal preference would be "dir/", as it gets across the idea
 > > that "dir" is a directory and i want all of it. thoughts on that as
 > > well? i'm currently perusing the OE code base to see the general
 > > consensus on this. is there one?
 > 
 > That's more a question of coding style, which the OE maintainers etc
 > generally doesn't care about very much (unless you start asking about
 > unifying oe-core and meta-oe with respect to indenting with tabs or
 > spaces...).
 > 
 > >   more decidedly strange questions coming shortly ...
 > >
 > > rday
 > >
 > >
 > > 
 > >
 > 
 > 
 > 
 > 

Re: [OE-core] curious about weirdness in some FILES_${PN} settings

[Robert P. J. Day]

On Tue, 23 Mar 2021, Damian Wrobel wrote:

>  ---- On Mon, 22 Mar 2021 20:27:42 +0100 Andre McCurdy <armccurdy@gmail.com> wrote ----
>  > On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>  > >   (warning: i've just been handed an existing OE code base, and i'm
>  > > going to ask some questions about some head-scratching things i'm
>  > > finding in it, so be prepared for weird questions.)
>  > >
>  > >   in one recipe, i see the following snippet:
>  > >
>  > >   FILES_${PN} += "/etc"
>  > >   FILES_${PN} += "/etc/mosquitto"
>  > >   FILES_${PN} += "/etc/mosquitto/config"
>  > >   ... etc etc ...
>  > >
>  > > first, i'm taken aback by the hardcoding of "/etc" rather than using,
>  > > you know, "${sysconfdir}", so i'm *assuming* that unless someone was
>  > > doing something spectacularly clever here, that just can't be right.
>  >
>  > Nothing clever going on, it's just a bug. In general, using /etc
>  > instead of ${sysconfdir} etc will appear to work fine until you add
>  > BBCLASSEXTEND and try to build <recipe>-native, at which point things
>  > will start to fail in mysterious ways (since native.bbclass over-rides
>  > the default values of ${sysconfdir} etc).
>  >
>  > In this particular case, you might still get away with it since
>  > FILES_${PN} is related to packaging and -native recipes don't do any
>  > packaging but it's still not right.
>  >
>  > >   more to the point, the above seems redundant -- once you've added
>  > > "/etc", isn't the rest just superfluous? i'm not sure what the
>  > > original developer was going for here. thoughts?
>  >
>  > Yes, and even beyond that, ${sysconfdir} is handled by the default
>  > packaging rules, so any extra packaging rules related to adding files
>  > from /etc to the default package are redundant.
>  >
>  > >   finally, if i wanted to add all of some directory, say "dir", it was
>  > > my understanding that all of the following were equivalent (hmmmm,
>  > > short of picking up hidden files, i guess):
>  > >
>  > >   dir
>  > >   dir/
>  > >   dir/*
>  > >
>
> Normally in the RPM world it matters if you gonna own a directory with all files in it
> or just the directory or the file inside the directory but not the directory itself.
> You can read more about it in  Fedora packaging guidelines "Unowned Directories"[1].
>
> However, I'm not sure how this is implemented in yocto/bitbake if at all, as I couldn't find any
> similar recommendation in [2]. You can always check who owns what using rpm tools like rpmls, rpm -qlv
>
> Here is the real example from Fedora where the directory is owned by different package then
> files inside a folder:
>
> $ rpm -qf /etc/sysconfig/
> filesystem-3.14-2.fc32.x86_64
>
> $ rpm -qf /etc/sysconfig/atd
> at-3.1.23-4.fc32.x86_64
>
> This means that 'at' package doesn't need to create '/etc/sysconfig' directory and conversely removal of the
> 'at' package will not remove the '/etc/sysconfig' directory even if it was empty.
>
> [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
> [2] https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-FILES

  i'm familiar with the RPM packaging standard, and i'm fairly
confident that how it works doesn't map directly to how OE does this.

rday