On Tue, 2011-08-02 at 09:49 -0500, Mark Hatle wrote:
> On 8/2/11 8:46 AM, Phil Blundell wrote:
> > On Mon, 2011-08-01 at 19:17 -0500, Mark Hatle wrote:
> >> The following allows RPM to generate the SDK image, however without it
> >> we get a failure because the system has nothing that provides /bin/sh.
> >>
> >> Unfortunately the patch causes failures with ipk and deb packages because
> >> they can not have filenames within their RPROVIDES. I'm looking for some
> >> type of a resolution to the issue, the only thing I can think of is to
> >> add a way to manually add a FILERPROVIDE for the items. This will require
> >> changes to the way FILERPROVIDE is currently generated... but I'm not sure
> >> how we can automatically generate the FILERPROVIDE values without the use
> >> of
> >> python...
> >>
> >> Any suggestions?
> >
> > It's never really been the intent that update-alternatives should put
> > the name of the link being provided into RPROVIDES. If you want to
> > solve the specific problem with /bin/sh then just adding RPROVIDES_${PN}
> > += "virtual-bourne-shell" or something to bash and busybox is probably
> > the easiest way of doing that.
> >
> > I wouldn't be entirely opposed to the concept of what you're proposing
> > here, though. Something like:
> >
> > RPROVIDES_${PN} += "${@' '.join(map(lambda x:
> > legitimize_package_name("virtual-path-" + x), filter(lambda x: x != '',
> > [ d.getVar('ALTERNATIVE_LINK', True) or '' ] +
> > (d.getVar('ALTERNATIVE_LINKS', True) or '').split())))}"
> >
> > might be what you want, perhaps. I'm not sure that the resulting
> > virtual names will be very pretty though.
>
> Hmm.. Coming from the RPM world, the virtual-path- because we can't just
> "provide" a file in the system seems a bit wonky to me. But it should be able
> to work. For RPM at least, we'd want a reversing function to turn virtual
> paths
> back into real paths.
>
> If I have time today, I'll try to implement a proof of concept and see if I
> can
> get it to work reasonably well.
Just to be clear for Phil's benefit, RPM natively supports file based
dependencies, so a dependency of "/bin/sh" is automatically fulfilled by
a package which contains "/bin/sh". Some dependencies such as the
shebang in scripts are automatically added to packages and resolved by
rpm.
I did chase down this bug a bit and it seems that if you "bitbake
meta-toolchain-game" you hit an error about /bin/sh being missing but if
you "bitbake busybox; bitbake meta-toolchain-gmae" it will work. This is
due to busybox shipping a /bin/sh.
The question is therefore how to handle this on the deb/ipk side and
ensure we get consistency between the behaviours of the different
backends. I thought with the rpm filedeps code in do_package, we were
adding things like /bin/sh dependencies to the other package formats but
now I'm not so sure.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
