On Wed, 2011-08-03 at 09:41 -0500, Mark Hatle wrote:
> On 8/3/11 7:20 AM, Richard Purdie wrote:
> > 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.
>
> Due to deb/ipk not handling file based dependencies, they are filtered out on
> the creation of the deb/ipk packages. The original intention was to use them,
> but it wasn't possible at the time. Simply adding a ton of file-based
> dependencies seemed like a huge mistake as well. (We'd have to add virtual
> provides for all of the virtual requirements....)
>
> We could certainly select a few specific requirements and scan for and use
> those
> to catch obvious issues, such as perl, sh, bash, env/python... but it's still
> only a partial solution to the real issue.
Short term I'm tempted to buy us some time and do this (rpm specific):
package_rpm: Ensure alternatives links are reflected in rpm package dependencies
Currently, if a file is provided as an alternative link within the package, rpm
doesn't see the dependency. This works out badly for dependencies such as
/bin/sh
which scripts might require.
Since rpm detects and adds these dependencies we do need to ensure the
dependency
information in the packages is correct. This patch does so for the rpm backend
ensuring internal consistency whilst the approach for addressing this problem in
the other package backends is considered.
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
---
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index abedc68..c44fdcc 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -501,6 +501,10 @@ python write_specfile () {
splitrconflicts = bb.data.getVar('RCONFLICTS', localdata,
True) or ""
splitrobsoletes = []
+ # For now we need to manually supplement RPROVIDES with any
update-alternatives links
+ if pkg == d.getVar("PN", True):
+ splitrprovides = splitrprovides +
(d.getVar('ALTERNATIVE_LINK', True) or '') + (d.getVar('ALTERNATIVE_LINKS',
True) or '')
+
# Gather special src/first package data
if srcname == splitname:
srcrdepends = splitrdepends
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
