Optional runtime depends have been an issue in gentoo for a long time. The main problem is that if pkg foo has an optional runtime depend on bar such as RDEPEND="baz? ( bar )" when the use flag is toggled it will force a rebuild of foo for no reason. I brought this discussion to irc which explains it better than I can: 21:48 < Zero_Chaos> zmedico: I got another stupid question for you 21:49 < Zero_Chaos> zmedico: If I RDEPEND="blah? ( foo )" what would it take to teach portage that is obviously a runtime dep not a build time dep which means I don't need to rebuild the package when the use flag changes? 22:00 < zmedico> Zero_Chaos: mgorny wrote a glep for that: http://www.gentoo.org/proj/en/glep/glep-0062.html 22:01 < Zero_Chaos> zmedico: no, he introduced IUSE_RUNTIME, I'm wondering why we can't just assume it's obvious if it's in RDEP and not DEP... 22:02 < Zero_Chaos> or maybe PDEPEND suits better? 22:02 < Zero_Chaos> point is, it should be obvious without IUSE_RUNTIME imho 22:04 < Zero_Chaos> zmedico: am I missing something critical? 22:06 < zmedico> Zero_Chaos: PDEPEND should work. RDEPEND, maybe if you subtract the intersection with DEPEND 22:07 < Zero_Chaos> zmedico: so if a conditional is in RDEPEND or PDEPEND, and NOT in DEPEND, why can't we assume that it's a runtime dep and not rebuild the package? it seems to me that anything not in DEPEND shouldn't trigger a rebuild. 22:10 < zmedico> Zero_Chaos: yeah, so this is a modification to --changed-use? 22:11 < Zero_Chaos> zmedico: and --newuse but yeah 22:11 < Zero_Chaos> zmedico: bikeshedding and protocol aside, what do you think? it seems rational to me 22:11 < zmedico> yeah, can add a new flag to toggle it 22:12 < Zero_Chaos> zmedico: like a --runtime-use-switching=y or something? 22:13 < zmedico> yeah 22:13 < Zero_Chaos> zmedico: want a bug? 22:13 < zmedico> sure :)
I'd like to add one flag to tweak the --newuse/--changed-use behaviors, and another one to toggle dynamic re-evaluation of conditional runtime deps (similar effects to IUSE_RUNTIME/GLEP 62).
I fear this may not be PMS compliant, because it changes the behavior of all EAPIs.
(In reply to comment #2) > I fear this may not be PMS compliant, because it changes the behavior of all > EAPIs. I don't recall PMS defining how to handle use flag changes at all, would you care to point me to the right section to re-read?
(In reply to comment #2) > I fear this may not be PMS compliant, because it changes the behavior of all > EAPIs. We consider it as behavior that is not defined by PMS, similarly to preserve-libs. It shouldn't interfere with PMS compliant package managers. When the option to re-evaluate dependencies is enabled, emerge will have to update the dependencies and USE in /var/db/pkg, in order to ensure that --depclean and PMS compliant package managers interpret it correctly.
also this could break packages where we have RDEPEND="foo? ( bar/mo )" but also src_prepare() { use foo && sed -i -e 's/foo//' somescript || die } so where only slight modifications to script files or such are done and we don't have any real build-time dependency as in linking stuff
(i'm on pms-bugs@)
(In reply to comment #5) > also this could break packages where we have > > RDEPEND="foo? ( bar/mo )" > > but also > > src_prepare() { > use foo && sed -i -e 's/foo//' somescript || die > } > > > so where only slight modifications to script files or such are done and we > don't have any real build-time dependency as in linking stuff That's true. Maybe if we restrict our new behavior to PDEPEND conditionals, then that will allow these cases to be distinguishable.
(In reply to comment #5) > also this could break packages where we have > > RDEPEND="foo? ( bar/mo )" > > but also > > src_prepare() { > use foo && sed -i -e 's/foo//' somescript || die > } > > > so where only slight modifications to script files or such are done and we > don't have any real build-time dependency as in linking stuff Well, I think that implementing this in EAPI will actually deprecate those kind of solutions since they would cause unnecessary rebuilds. (In reply to comment #7) > That's true. Maybe if we restrict our new behavior to PDEPEND conditionals, > then that will allow these cases to be distinguishable. And now we're back to my original proposal. Still, I'm not entirely convinced by this. We're making assumptions about behavior of USE flags based solely on whether they appear in a particular DEPEND variable or not.
> Still, I'm not entirely convinced by this. We're making assumptions about > behavior of USE flags based solely on whether they appear in a particular > DEPEND variable or not. I'm fine with hiding this behind a non-default FEATURE flag to start. Personally I think it could be great benefit, HOWEVER, a change like this truly needs testing.
Even if the use-controlled dependency is in PDEPEND, the ebuild could install some support files for it etc bla bla... I don't like it since it might trigger strange bugs. IUSE_RUNTIME would be better imho.
(In reply to Andreas K. Hüttel from comment #10) > Even if the use-controlled dependency is in PDEPEND, the ebuild could > install some support files for it etc bla bla... I don't like it since it > might trigger strange bugs. IUSE_RUNTIME would be better imho. Do you know what blocked http://www.gentoo.org/proj/en/glep/glep-0062.html ? Thanaks for the info
(In reply to Pacho Ramos from comment #11) > (In reply to Andreas K. Hüttel from comment #10) > > Even if the use-controlled dependency is in PDEPEND, the ebuild could > > install some support files for it etc bla bla... I don't like it since it > > might trigger strange bugs. IUSE_RUNTIME would be better imho. > > Do you know what blocked http://www.gentoo.org/proj/en/glep/glep-0062.html ? > A reference implementation.
(In reply to Julian Ospald (hasufell) from comment #12) > > Do you know what blocked http://www.gentoo.org/proj/en/glep/glep-0062.html ? > > A reference implementation. Might be more accurate to say that a lack of reference implementation has blocked people from seeing all its other faults... The way to go is SDEPEND, not this.
(In reply to Ciaran McCreesh from comment #13) > (In reply to Julian Ospald (hasufell) from comment #12) > > > Do you know what blocked http://www.gentoo.org/proj/en/glep/glep-0062.html ? > > > > A reference implementation. > > Might be more accurate to say that a lack of reference implementation has > blocked people from seeing all its other faults... The way to go is SDEPEND, > not this. thanks for the user input
IUSE_RUNTIME effectively introduces a new type of package that blends attributes of portage's existing ebuild, binary, and installed package types. It will be a very nice feature to have for project binhost, since it makes binary package dependencies more flexible like ebuild dependencies.
Since implementing the proposal in full would require major changes (i.e. having Portage actually perform "rebuilds without rebuilding"), how about we limit its scope to installing binary packages, for the time being? The rough idea is that Portage would ignore the "runtime" flags when matching binpkg USE flags, and use the user-supplied values when resolving dependencies. This would improve binary package matching and let people who use FEATURES=buildpkg benefit from most of IUSE_RUNTIME. That said, I don't know if we keep full dependency strings in binary package metadata, or flatten it.
