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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151251):
https://lists.openembedded.org/g/openembedded-core/message/151251
Mute This Topic: https://lists.openembedded.org/mt/82577515/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
