On Mon, 15 Dec 2025, 15:57 Mark Hatle, <[email protected]> wrote:
> > > On 12/14/25 11:56 AM, Adam Blank via lists.openembedded.org wrote: > > I've recently come across a problem, which has apparently been around > for a long > > time, and yet has somehow remained unnoticed. > > > > Facts: > > - bash and busybox recipes conditionally (based on usrmerge in the > > DISTRO_FEATURES) declare some RPROVIDES > > - what they declare in RPROVIDES are actually file paths - e.g. > '/bin/sh', > > '/bin/ash' or '/bin/bash' > > - resulting entries in their packagedata are "correct" - i.e. 'RPROVIDES > = > > /bin/sh /bin/bash' > > - resulting entries in their buildhistory are mangled - i.e. 'RPROVIDES > = bib > > bin bash sh' > > > > Thesis: > > - such entries in RPROVIDES (or any other package namespace related > variable) > > are an error (at least looking at what insane.bbclass deems an > acceptable > > package name) > > - buildhistory should be consistent in its processing of package names > with > > packagedata > > > > I'd like to ask for your comments as to what would be the best way to > approach > > this. My view would be to fix the recipes, the buildhistory.bbclass but > also > > make sure that all package related variables are guarded in equal degree > in all > > relevant stages (e.g. in the insane.bbclass). > > I don't believe this is an error. When packages are processed, any > scripts are > evaluated to determine what they require to be run. > Thanks. And what's your view on the difference in behaviour between buildhistory and packagedata? > A LARGE number of package have: > > #! /bin/bash > #! /bin/sh > > and other values, which are inserted into the RDEPENDS for that > file/package. > > Normally these values are resolved by the package manager to the list of > files > installed. Something installs /bin/bash, so it must then provide > /bin/bash. > > HOWEVER, there are two cases where this is not true. The first is with > "update > alternatives", /bin/sh for instance isn't supplied directly, but bash (and > other > posix shells) can be listed as the 'alternative' for /bin/sh. So > something in > the system says "I supply /bin/sh, even though I don't actually have the > _file_ > /bin/sh." (This is usually the ash package BTW.) > > The second case is the one you are asking about, usrmerge. In the case of > usrmerge, the files live in /usr/bin, not /bin. So the package manager > has no > way to know that '/usr/bin/sh' satisfies '/bin/sh'. So we require a > manual > RPROVIDE for this case. > > (/usr/bin/env is another common RDEPENDS. So even if usrmerge were > reversed, > all of the file installed into /bin and /sbin, instead of /usr/bin and > /usr/sbin > the same issue would be occurring.) > > > Thanks, > > Adam > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2212): https://lists.openembedded.org/g/openembedded-architecture/message/2212 Mute This Topic: https://lists.openembedded.org/mt/116779688/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
