Summary: | sys-apps/portage: better optional runtime dependency handling with IUSE_RUNTIME (GLEP 62) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Rick Farina (Zero_Chaos) <zerochaos> |
Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | erikdenstore+gbugs, esigra, gentoo, hasufell, mgorny, pacho, pms, sam, wuodan-gentoo, yac |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=424283 https://bugs.gentoo.org/show_bug.cgi?id=772380 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 155723, 373323 |
Description
Rick Farina (Zero_Chaos)
2013-01-23 03:19:05 UTC
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. |