making the meaning of "FILES_${PN}-bin" a little more obvious?

making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

  more nitpickery, but i note in OE's current bitbake.conf the
initially odd definitions:

  FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
     ... snip ...

  FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"

i say "odd" since someone perusing that file could be confused, first,
that that "-bin" package definition overlaps with the base package
file list and, more, that just above that, the definition of PACKAGES
doesn't include the "-bin" package:

  PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
      ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"

so anyone currently RTFS is likely to stop and think, "what the heck
is the '-bin' package defined for if it's not even included in the
normal package list?"

  of course, one need to consult lib_package.bbclass to finally
understand what its purpose is:

  PACKAGE_BEFORE_PN = "${PN}-bin"

but if that's the only purpose for that package definition, would it
not make more sense to just move it to lib_package.bbclass so it's
next to the variable setting that actually causes it to be processed?

  of course it works as is, it just seems unnecessarily confusing,
unless there's some subtle ordering requirement happening here.

rday

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Richard Purdie]

On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
>   more nitpickery, but i note in OE's current bitbake.conf the
> initially odd definitions:
> 
>   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
>      ... snip ...
> 
>   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> 
> i say "odd" since someone perusing that file could be confused, first,
> that that "-bin" package definition overlaps with the base package
> file list and, more, that just above that, the definition of PACKAGES
> doesn't include the "-bin" package:
> 
>   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
>       ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> 
> so anyone currently RTFS is likely to stop and think, "what the heck
> is the '-bin' package defined for if it's not even included in the
> normal package list?"
> 
>   of course, one need to consult lib_package.bbclass to finally
> understand what its purpose is:
> 
>   PACKAGE_BEFORE_PN = "${PN}-bin"
> 
> but if that's the only purpose for that package definition, would it
> not make more sense to just move it to lib_package.bbclass so it's
> next to the variable setting that actually causes it to be processed?
> 
>   of course it works as is, it just seems unnecessarily confusing,
> unless there's some subtle ordering requirement happening here.

I suspect such a change may break as some other recipe may use ${PN}-bin
but not the class. We'd need a careful audit to figure it out...

Cheers,

Richard

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

On Tue, 4 May 2021, Richard Purdie wrote:

> On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> >   more nitpickery, but i note in OE's current bitbake.conf the
> > initially odd definitions:
> >
> >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> >      ... snip ...
> >
> >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> >
> > i say "odd" since someone perusing that file could be confused, first,
> > that that "-bin" package definition overlaps with the base package
> > file list and, more, that just above that, the definition of PACKAGES
> > doesn't include the "-bin" package:
> >
> >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> >       ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> >
> > so anyone currently RTFS is likely to stop and think, "what the heck
> > is the '-bin' package defined for if it's not even included in the
> > normal package list?"
> >
> >   of course, one need to consult lib_package.bbclass to finally
> > understand what its purpose is:
> >
> >   PACKAGE_BEFORE_PN = "${PN}-bin"
> >
> > but if that's the only purpose for that package definition, would it
> > not make more sense to just move it to lib_package.bbclass so it's
> > next to the variable setting that actually causes it to be processed?
> >
> >   of course it works as is, it just seems unnecessarily confusing,
> > unless there's some subtle ordering requirement happening here.
>
> I suspect such a change may break as some other recipe may use
> ${PN}-bin but not the class. We'd need a careful audit to figure it
> out...

  i know this seems like a minor point, but i'll expand on this a bit
more, then i'll shut the hell up about it.

  as i read it, the *only* context where a package called
"FILES_${PN}-bin" makes sense is to separate the binaries from an
obvious library package, where -- in the overwhelming number of cases
-- any binaries that accompany a library package are non-essential
executables for things like, say, configuration, or a demo program, or
possibly debugging, that sort of thing.

  so you're absolutely right -- combining the package definition with
its inclusion in the PACKAGES variable in lib_package.bbclass might
very well break something, but i submit that that's something that can
then be cleaned up, the object being that, whenever anyone sees
"FILES_${PN}-bin", they know *exactly* what it's being used for and
the code is clearer. if any recipe is using that variable for any
other reason, i submit that it's being misused and should be "fixed."

  anyway, i'll shut up now and find something else to gripe about. :-)


rday

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Richard Purdie]

On Tue, 2021-05-04 at 16:31 -0400, Robert P. J. Day wrote:
> On Tue, 4 May 2021, Richard Purdie wrote:
> 
> > On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > >   more nitpickery, but i note in OE's current bitbake.conf the
> > > initially odd definitions:
> > > 
> > >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> > >      ... snip ...
> > > 
> > >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> > > 
> > > i say "odd" since someone perusing that file could be confused, first,
> > > that that "-bin" package definition overlaps with the base package
> > > file list and, more, that just above that, the definition of PACKAGES
> > > doesn't include the "-bin" package:
> > > 
> > >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> > >       ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> > > 
> > > so anyone currently RTFS is likely to stop and think, "what the heck
> > > is the '-bin' package defined for if it's not even included in the
> > > normal package list?"
> > > 
> > >   of course, one need to consult lib_package.bbclass to finally
> > > understand what its purpose is:
> > > 
> > >   PACKAGE_BEFORE_PN = "${PN}-bin"
> > > 
> > > but if that's the only purpose for that package definition, would it
> > > not make more sense to just move it to lib_package.bbclass so it's
> > > next to the variable setting that actually causes it to be processed?
> > > 
> > >   of course it works as is, it just seems unnecessarily confusing,
> > > unless there's some subtle ordering requirement happening here.
> > 
> > I suspect such a change may break as some other recipe may use
> > ${PN}-bin but not the class. We'd need a careful audit to figure it
> > out...
> 
>   i know this seems like a minor point, but i'll expand on this a bit
> more, then i'll shut the hell up about it.
> 
>   as i read it, the *only* context where a package called
> "FILES_${PN}-bin" makes sense is to separate the binaries from an
> obvious library package, where -- in the overwhelming number of cases
> -- any binaries that accompany a library package are non-essential
> executables for things like, say, configuration, or a demo program, or
> possibly debugging, that sort of thing.
> 
>   so you're absolutely right -- combining the package definition with
> its inclusion in the PACKAGES variable in lib_package.bbclass might
> very well break something, but i submit that that's something that can
> then be cleaned up, the object being that, whenever anyone sees
> "FILES_${PN}-bin", they know *exactly* what it's being used for and
> the code is clearer. if any recipe is using that variable for any
> other reason, i submit that it's being misused and should be "fixed."

I have no objection to the idea, I just wanted to make it clear there is 
work that has to be done to do this. If someone steps up and does the work,
great. What I don't particularly want is an untested patch which breaks 
things and then I get forced into cleaning up the mess.

Cheers,

Richard

Re: [OE-core] making the meaning of "FILES_${PN}-bin" a little more obvious?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 3399 bytes --]

On Tue, 4 May 2021, Richard Purdie wrote:

> On Tue, 2021-05-04 at 16:31 -0400, Robert P. J. Day wrote:
> > On Tue, 4 May 2021, Richard Purdie wrote:
> >
> > > On Tue, 2021-05-04 at 09:31 -0400, Robert P. J. Day wrote:
> > > >   more nitpickery, but i note in OE's current bitbake.conf the
> > > > initially odd definitions:
> > > >
> > > >   FILES_${PN} = "${bindir}/* ${sbindir}/* ...'
> > > >      ... snip ...
> > > >
> > > >   FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
> > > >
> > > > i say "odd" since someone perusing that file could be confused, first,
> > > > that that "-bin" package definition overlaps with the base package
> > > > file list and, more, that just above that, the definition of PACKAGES
> > > > doesn't include the "-bin" package:
> > > >
> > > >   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev \
> > > >       ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
> > > >
> > > > so anyone currently RTFS is likely to stop and think, "what the heck
> > > > is the '-bin' package defined for if it's not even included in the
> > > > normal package list?"
> > > >
> > > >   of course, one need to consult lib_package.bbclass to finally
> > > > understand what its purpose is:
> > > >
> > > >   PACKAGE_BEFORE_PN = "${PN}-bin"
> > > >
> > > > but if that's the only purpose for that package definition, would it
> > > > not make more sense to just move it to lib_package.bbclass so it's
> > > > next to the variable setting that actually causes it to be processed?
> > > >
> > > >   of course it works as is, it just seems unnecessarily confusing,
> > > > unless there's some subtle ordering requirement happening here.
> > >
> > > I suspect such a change may break as some other recipe may use
> > > ${PN}-bin but not the class. We'd need a careful audit to figure it
> > > out...
> >
> >   i know this seems like a minor point, but i'll expand on this a bit
> > more, then i'll shut the hell up about it.
> >
> >   as i read it, the *only* context where a package called
> > "FILES_${PN}-bin" makes sense is to separate the binaries from an
> > obvious library package, where -- in the overwhelming number of cases
> > -- any binaries that accompany a library package are non-essential
> > executables for things like, say, configuration, or a demo program, or
> > possibly debugging, that sort of thing.
> >
> >   so you're absolutely right -- combining the package definition with
> > its inclusion in the PACKAGES variable in lib_package.bbclass might
> > very well break something, but i submit that that's something that can
> > then be cleaned up, the object being that, whenever anyone sees
> > "FILES_${PN}-bin", they know *exactly* what it's being used for and
> > the code is clearer. if any recipe is using that variable for any
> > other reason, i submit that it's being misused and should be "fixed."
>
> I have no objection to the idea, I just wanted to make it clear there is 
> work that has to be done to do this. If someone steps up and does the work,
> great. What I don't particularly want is an untested patch which breaks 
> things and then I get forced into cleaning up the mess.

  i'll do an audit of a number of layers i have on my system, and if
it looks horrendous, i'll just drop the idea. if not, i'll work on the
patch.

rday