irclog2html for #oe on 20050106

00:00.51*** join/#oe chouimat|ibook (~dieu@r2351064.cidc.net)
00:01.40*** join/#oe chouimat (~dieu@r2351064.cidc.net)
00:21.05pb_kergoth: in the current implementation?  shlibdeps is in package.bbclass, not debian.
00:21.14pb_all that debian.bbclass does is set the policy for library naming.
00:21.41kergothahh right
00:27.16CosmicPenguinI wonder why AC_CHECK_FILE is illegal for xcompiling
00:27.21trekewill shlibdeps work with redhat naming though?
00:27.33trekeI thought something broke in redhat naming
00:28.03pb_yeah, it should be fine
00:28.33pb_I think there are a few packages that have hard-coded debian style names in their RDEPENDS, but not many.
00:29.04kergothshould really have a convenience function to call out to do the name mangling explicitly for those packages
00:32.00pb_the trouble is that the name mangling is contingent on the (contents of the) files in the package.
00:32.25pb_you can't easily say "tell me what package <blah> would rename to", without having a copy of that package on hand to look at.
00:33.34kergothah, good point
00:34.05*** join/#oe CoreDump|hom (~mhentges@xdsl-213-196-245-40.netcologne.de)
00:34.14pb_the only thing we could do would be to record a mapping table somewhere in staging.  that way, as long as the depended-on package had been built before the one doing the depending, you could figure it out.
00:34.31trekethat sounds like a safe assumption
00:35.25pb_as long as you adhere to the "if in RDEPENDS, also in DEPENDS" credo, yeah
00:35.56pb_I'm not sure if that's still controversial.
00:36.19pb_well, I guess we could require it in this specific case anyway
00:36.32trekeare there cases where shlibdeps could find a dependency that wouldnt actually be required to build a package?
00:36.53pb_no; none of this applies to shlibdeps.
00:37.01trekeah. then ignore me
00:37.07pb_shlibdeps, by definition, will only find dependencies on packages that have already been built, and will always get the names right.
00:37.44pb_the case that causes trouble is where a .bb file explicitly mentions some random package in its RDEPENDS.
00:38.05kergoththe most common case is that of an interpreter.
00:38.10kergothwhich isnt necessarily required to build the package
00:38.13kergothonly to run it
00:38.17pb_yeah, exactly
00:39.11pb_my contention has always been that, since you need some way to ensure that the interpreter has been built by the time you come to do image construction, you should put it in DEPENDS even though it isn't involved in the act of building your package.
00:39.39trekefair point
00:39.52pb_otherwise you'll wind up in do_rootfs with this dangling RDEPENDS, and oe will have no clue how to make a package to fulfil it.
00:42.00Mech422kergoth: that article any good ?
00:42.05Mech422lamson, that is
00:42.46*** join/#oe chouimat (~dieu@r2351064.cidc.net)
00:44.11trekewhere did oe commander go?
00:44.35Mech422~ oecommander
00:44.41Mech422blah
00:44.47Mech422treke: whats an oe commander ?
00:45.03bluelightningone above an oe captain? :)
00:45.23trekeah here we go, we still have the oe.deprecated repo I can pull it from
00:45.39Mech422bluelightning: :-)
00:45.39trekeMech422: an oe front end.
00:46.07Mech422treke: is there someplace I can RTFM about it ?
00:46.14trekeno
00:46.17pb_treke: I think mickey pulled it from the repo to stop it going into bitbake 1.0
00:46.26*** join/#oe CIA-4 (~CIA@to.je.spocco.com)
00:46.40trekeyeah just wanted to make sure the source didn't completely disappear
00:50.11bluelightningwho is in charge of hotplug in oe?
00:50.37bluelightning(no maintainer in the .bb)
00:51.35pb_I think kergoth looks after it, mostly.
00:53.19CosmicPenguinlack of maintainer implies kergoth
00:53.22CosmicPenguinor pb_
00:55.19bluelightningok