some ideas about DEPEND/RDEPEND
(zhllg) Is it possible that a runtime dependency is not a build time dependency? or could a package be built without some package, but require it in order to run?
(igli) yes
(zhllg) igli, any example?
(igli) not necessarily required at run time; in any case eg an app that runs a cmd
(igli) might not need to be built against the other app
(zhllg) oh that is true
(igli) synfig has run time deps for i think jpeg and stuff
(igli) need to work on ebuild.. :(
(zhllg) igli, what about the runtime dependency is a library
(igli) usu if it's a dep against a lib, it's compile time
(marienz) both.
(igli) depends on whether it looks for the .h files
(marienz) normally both.
(igli) oh sorry, yes runtime as well of course
(igli) as lib needed on system when app is running :) doh!
(zhllg) then IMHO maybe in that case just specify the dependency in RDEPEND is enough, what do you think?
(marienz) you normally need the lib present at build time or the link will fail.
(zhllg) yes
(igli) yup
(igli) zhllg: if only RDEPEND that means the app is not usually linked as it would be with a library
(igli) library depend is usually compile time as the app will call the lib code
(igli) not the same as say running a cmd
(zhllg) actually i am not quite sure about the implication of DEPEND, if not speficy the dep in DEPEND, will the dep be merged before the dependent ?
(igli) eg rdepend on pci-utils or something
(me22) many perl scripts don't need any building, but will need packages or commands to run
(igli) zhllg: if not specified, not a dep
(zhllg) igli, i mean just specify it in RDEPEND
(zhllg) not DEPEND
(igli) ok then not necessarily
(zhllg) igli, you mean in that case dep maybe absent when emerging the dependent?
(igli) yeah might be emerged just after as it's not required for building the pkg
(igli) if it were would be a compile time dep (ie in DEPEND)
(marienz) zhllg: it will normally be merged early enough even if it's just in RDEPEND but this is not guaranteed.
(marienz) zhllg: if you need it at build time you should put it in DEPEND too.
(zhllg) marienz, actually today i encountered a problem that rare people will come across
(zhllg) i try cross compile kde using xmerge script
(zhllg) the host system has modular kde installed
(igli) omg
(zhllg) i want to install non-modular kde in target system
(marienz) why am I not surprised that doesn't actually work
(zhllg) however, conflicts occurred
* Fedman (n=Fedman@chello084112150156.4.11.vie.surfer.at) has joined #gentoo-dev-help
(marienz) the ebuild format is not advanced enough to properly deal with cases like this.
(igli) i need someone to test an update script :)
(marienz) the problem is probably related to the fact that you tend to need some of the DEPENDS on the build system, not the target.
(zhllg) the cause of the conflict is emerge want to install kdebase and the like in my host system
(marienz) (think autoconf / automake deps)
(marienz) nod.
(igli) zhllg: you can't do it without the same sort of setup on both
(zhllg) as kdebase is listed as a DEPEND
(marienz) I think to work around this we need to split DEPEND up into hostdepends and builddepends
(marienz) if you know what I mean.
(zhllg) igli, actually i have setup an overlay
(zhllg) and it works now, i want to see if the cross compile would succeed
(marienz) well, those words I use make no sense, but I think you get the general idea :)
(igli) what's that got to do with it?
(marienz) the problem is this requires changing all the ebuilds and is hard to get right if you don't crosscompile everything to test :)
marienz me22 masterdriverz mzbot mjolnir40k mpagano mren
(igli) marienz: i knew what you meant but it seems wrong written down
(marienz) it does?
(zhllg) marienz, that sounds like a good idea
(igli) host depends seems like rdeps
(marienz) yeah, I didn't quite use the right words
(igli) well deps for the machine which will install the pkg
(marienz) build-time deps that are run on the build system vs build-time deps that are linked against (need to be present in the target system)
(igli) deps for the machine which will install the pkg cover it?
(marienz) you'd end up with three kinds of deps
(marienz) buildtime deps for the build system, buildtime for the target system, runtime (for the target system)
(marienz) I think.
(igli) i don;t :P
(igli) buildtime for target makes no sense; pkg is already built
(marienz) err
(marienz) no?
(marienz) *buildtime* for target. At that time the package is obviously not built yet, or it wouldn't be buildtime
(marienz) (these deps would be libraries that are linked in)
(igli) what's the build system do then?
(marienz) buildtime target dep: dev-libs/blah
(marienz) buildtime host dep: autoconf/automake/etc
(marienz) s/host/buildsystem/
(zhllg) or, we specify that DEPEND is disjoint from RDEPEND, categorize libs as RDEPEND, and require all RDEPEND be emerged before the dependent
(marienz) that'd be a bad idea since RDEPEND is useful to avoid circular deps.
(zhllg) oops
(marienz) and to avoid pulling in unneeded deps at build time.
(igli) yeah well buildtime target dep: dev-libs/blah seems same as redepend
(zhllg) or, splite RDEPEND, libs and non-libs(those need to be system()ed)
(igli) what for?
(zhllg) avoid circular dep? could achieve that?
(zhllg) i am not sure, just an idea
(igli) can't see it; you appear to be talking about rdepends
(zhllg) yeah, "(zhllg) or, splite RDEPEND"
(igli) sorry the prior conversation about target deps was effectively rdepends
* zzam (n=zzam@gentoo/developer/zzam) has joined #gentoo-dev-help
* ChanServ gives channel operator status to zzam
* Jell-O-Fishi (n=Jellyfis@bzq-84-108-253-224.cablep.bezeqint.net) has joined #gentoo-dev-help
(zhllg) i agree
(zhllg) so i suggest to splite RDEPEND into two RDEDENDs, libs(target deps in your word), and non-libs
(igli) yes
(zhllg) igli, any example?
(igli) not necessarily required at run time; in any case eg an app that runs a cmd
(igli) might not need to be built against the other app
(zhllg) oh that is true
(igli) synfig has run time deps for i think jpeg and stuff
(igli) need to work on ebuild.. :(
(zhllg) igli, what about the runtime dependency is a library
(igli) usu if it's a dep against a lib, it's compile time
(marienz) both.
(igli) depends on whether it looks for the .h files
(marienz) normally both.
(igli) oh sorry, yes runtime as well of course
(igli) as lib needed on system when app is running :) doh!
(zhllg) then IMHO maybe in that case just specify the dependency in RDEPEND is enough, what do you think?
(marienz) you normally need the lib present at build time or the link will fail.
(zhllg) yes
(igli) yup
(igli) zhllg: if only RDEPEND that means the app is not usually linked as it would be with a library
(igli) library depend is usually compile time as the app will call the lib code
(igli) not the same as say running a cmd
(zhllg) actually i am not quite sure about the implication of DEPEND, if not speficy the dep in DEPEND, will the dep be merged before the dependent ?
(igli) eg rdepend on pci-utils or something
(me22) many perl scripts don't need any building, but will need packages or commands to run
(igli) zhllg: if not specified, not a dep
(zhllg) igli, i mean just specify it in RDEPEND
(zhllg) not DEPEND
(igli) ok then not necessarily
(zhllg) igli, you mean in that case dep maybe absent when emerging the dependent?
(igli) yeah might be emerged just after as it's not required for building the pkg
(igli) if it were would be a compile time dep (ie in DEPEND)
(marienz) zhllg: it will normally be merged early enough even if it's just in RDEPEND but this is not guaranteed.
(marienz) zhllg: if you need it at build time you should put it in DEPEND too.
(zhllg) marienz, actually today i encountered a problem that rare people will come across
(zhllg) i try cross compile kde using xmerge script
(zhllg) the host system has modular kde installed
(igli) omg
(zhllg) i want to install non-modular kde in target system
(marienz) why am I not surprised that doesn't actually work
(zhllg) however, conflicts occurred
* Fedman (n=Fedman@chello084112150156.4.11.vie.surfer.at) has joined #gentoo-dev-help
(marienz) the ebuild format is not advanced enough to properly deal with cases like this.
(igli) i need someone to test an update script :)
(marienz) the problem is probably related to the fact that you tend to need some of the DEPENDS on the build system, not the target.
(zhllg) the cause of the conflict is emerge want to install kdebase and the like in my host system
(marienz) (think autoconf / automake deps)
(marienz) nod.
(igli) zhllg: you can't do it without the same sort of setup on both
(zhllg) as kdebase is listed as a DEPEND
(marienz) I think to work around this we need to split DEPEND up into hostdepends and builddepends
(marienz) if you know what I mean.
(zhllg) igli, actually i have setup an overlay
(zhllg) and it works now, i want to see if the cross compile would succeed
(marienz) well, those words I use make no sense, but I think you get the general idea :)
(igli) what's that got to do with it?
(marienz) the problem is this requires changing all the ebuilds and is hard to get right if you don't crosscompile everything to test :)
marienz me22 masterdriverz mzbot mjolnir40k mpagano mren
(igli) marienz: i knew what you meant but it seems wrong written down
(marienz) it does?
(zhllg) marienz, that sounds like a good idea
(igli) host depends seems like rdeps
(marienz) yeah, I didn't quite use the right words
(igli) well deps for the machine which will install the pkg
(marienz) build-time deps that are run on the build system vs build-time deps that are linked against (need to be present in the target system)
(igli) deps for the machine which will install the pkg cover it?
(marienz) you'd end up with three kinds of deps
(marienz) buildtime deps for the build system, buildtime for the target system, runtime (for the target system)
(marienz) I think.
(igli) i don;t :P
(igli) buildtime for target makes no sense; pkg is already built
(marienz) err
(marienz) no?
(marienz) *buildtime* for target. At that time the package is obviously not built yet, or it wouldn't be buildtime
(marienz) (these deps would be libraries that are linked in)
(igli) what's the build system do then?
(marienz) buildtime target dep: dev-libs/blah
(marienz) buildtime host dep: autoconf/automake/etc
(marienz) s/host/buildsystem/
(zhllg) or, we specify that DEPEND is disjoint from RDEPEND, categorize libs as RDEPEND, and require all RDEPEND be emerged before the dependent
(marienz) that'd be a bad idea since RDEPEND is useful to avoid circular deps.
(zhllg) oops
(marienz) and to avoid pulling in unneeded deps at build time.
(igli) yeah well buildtime target dep: dev-libs/blah seems same as redepend
(zhllg) or, splite RDEPEND, libs and non-libs(those need to be system()ed)
(igli) what for?
(zhllg) avoid circular dep? could achieve that?
(zhllg) i am not sure, just an idea
(igli) can't see it; you appear to be talking about rdepends
(zhllg) yeah, "(zhllg) or, splite RDEPEND"
(igli) sorry the prior conversation about target deps was effectively rdepends
* zzam (n=zzam@gentoo/developer/zzam) has joined #gentoo-dev-help
* ChanServ gives channel operator status to zzam
* Jell-O-Fishi (n=Jellyfis@bzq-84-108-253-224.cablep.bezeqint.net) has joined #gentoo-dev-help
(zhllg) i agree
(zhllg) so i suggest to splite RDEPEND into two RDEDENDs, libs(target deps in your word), and non-libs
Comments