Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 453618

Summary: sys-apps/portage: better optional runtime dependency handling with IUSE_RUNTIME (GLEP 62)
Product: Portage Development Reporter: Rick Farina (Zero_Chaos) <zerochaos>
Component: .tbz2 supportAssignee: Portage team <dev-portage>
Status: CONFIRMED ---    
Severity: normal CC: esigra, gentoo, hasufell, pacho, pms, sam, wuodan-gentoo, yac
Priority: Normal    
Version: 2.1   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=424283
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 155723, 373323    

Description Rick Farina (Zero_Chaos) gentoo-dev 2013-01-23 03:19:05 UTC
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 :)
Comment 1 Zac Medico gentoo-dev 2013-01-23 03:28:01 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).
Comment 2 Julian Ospald 2013-01-23 11:10:45 UTC
I fear this may not be PMS compliant, because it changes the behavior of all EAPIs.
Comment 3 Rick Farina (Zero_Chaos) gentoo-dev 2013-01-23 15:33:05 UTC
(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?
Comment 4 Zac Medico gentoo-dev 2013-01-23 15:36:39 UTC
(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.
Comment 5 Julian Ospald 2013-01-23 19:04:54 UTC
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
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-01-23 19:22:55 UTC
(i'm on pms-bugs@)
Comment 7 Zac Medico gentoo-dev 2013-03-29 18:42:37 UTC
(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.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-29 18:50:37 UTC
(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.
Comment 9 Rick Farina (Zero_Chaos) gentoo-dev 2013-05-29 23:59:17 UTC
> 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.
Comment 10 Andreas K. Hüttel archtester gentoo-dev 2013-06-17 18:40:18 UTC
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.
Comment 11 Pacho Ramos gentoo-dev 2013-06-30 07:38:13 UTC
(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
Comment 12 Julian Ospald 2013-06-30 10:09:55 UTC
(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.
Comment 13 Ciaran McCreesh 2013-06-30 11:10:31 UTC
(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.
Comment 14 Julian Ospald 2013-06-30 12:04:08 UTC
(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
Comment 15 Zac Medico gentoo-dev 2021-02-21 03:33:07 UTC
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.