Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/12 12:25 PM, Ciaran McCreesh wrote: > On Tue, 25 Sep 2012 12:19:21 -0400 Ian Stakenvicius > wrote: >>> a) How do we provide a good user interface for it? It took an >>> awful lot of experimenting to get the exheres-0 suggestions >>> user interface to be good, and it requires quite a bit more >>> information from the package side than this proposal is >>> providing. We want to avoid a REQUIRED_USE here... > >> Standard USE flag interface. This doesn't need anything special. >> Why will a user care if the flag doesn't trigger a package >> rebuild? > > One of the big selling points of suggestions is displaying them to > the user in a useful way (i.e. not via a bunch of einfo messages). > If you're not planning to allow for that, then you're losing a > primary benefit. > Must've missed that. I don't much care about showing things about optional program interation to users on emerge. In fact I see that as being pretty well useless. Use flag descriptions via metadata.xml , though, are *MUCH* more useful and imo suited entirely to this. (so again, standard use flag interface :) >>> b) How is consistency checking to be done? Related, what >>> happens when a runtime switch introduces a dependency that then >>> requires a non-runtime rebuild of the original package? > >> flag needs to be dropped from IUSE_RUNTIME, so the rebuild would >> occur. > > Uh, you're requiring ebuilds to ensure consistency of every > possible configuration of the entire tree? No, only on a per-atom basis. Maybe I didn't understand what it is you're referring to here. Could you elaborate the issue you are forseeing with a verbose example? >>> c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( =cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is >>> installed and flag is off? From experience, quite a few places >>> where you'd want to use suggestions will break if their >>> suggested package is installed but doesn't meet version or use >>> requirements. > >> Use flag deps are dealt with identically to the way they are now. >> the only difference , again, is that the package doesn't get >> re-emerged. The VDB would still update imo as if the package did >> get re-emerged (ie: USE and RDEPEND would update), to handle the >> use flag change info in metadata but from what I can tell nothing >> else would need to be touched. > > So such packages would just break at runtime? > Again, you lost me. The package is still added to the emerge list same as always, and its dependencies (based on USE) are evaluated same as always. The package just doesn't REBUILD, because a rebuild would not result in any change-on-disk. If there are conflicts in the emerge list then these would be reported just like if IUSE_RUNTIME wasn't used at all...?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBh3nIACgkQ2ugaI38ACPCilwD9HbOgxa99t0pRPI/wt4f6zvFT Lsjc140u+i15NIcatM8A/1tTC6LLIIFTBma13I0au9rdFRC9C5+oqTPI3bGpf3bx =0ebw -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 18:20:06 +0200 Michał Górny wrote: > Who is we? I believe REQUIRED_USE is one of the features which will be > available thanks to staying compatible with USE flags instead of > reinventing the wheel. Yes, but the REQUIRED_USE wheel is square, and gives a *very* bumpy ride to users. It also isn't particularly easy for developers. > > b) How is consistency checking to be done? Related, what happens > > when a runtime switch introduces a dependency that then requires a > > non-runtime rebuild of the original package? > > Then the package is rebuilt. Where's the problem? The problem is in implementing that correctly... It's certainly doable, but it's not entirely trivial, depending upon how you're doing resolution. > Handling of > REQUIRED_USE is not perfectly user friendly but it works. Like a square wheel, yes. > > c) How do we deal with flag? ( cat/dep[foo] ) or flag? > > ( >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is > > installed and flag is off? From experience, quite a few places > > where you'd want to use suggestions will break if their suggested > > package is installed but doesn't meet version or use requirements. > > Er, you mean how to deal with an optional dependency which is not > enabled at all? I mean the *entire* thing I wrote. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 25 Sep 2012 12:19:21 -0400 Ian Stakenvicius wrote: > > a) How do we provide a good user interface for it? It took an awful > > lot of experimenting to get the exheres-0 suggestions user > > interface to be good, and it requires quite a bit more information > > from the package side than this proposal is providing. We want to > > avoid a REQUIRED_USE here... > > Standard USE flag interface. This doesn't need anything special. Why > will a user care if the flag doesn't trigger a package rebuild? One of the big selling points of suggestions is displaying them to the user in a useful way (i.e. not via a bunch of einfo messages). If you're not planning to allow for that, then you're losing a primary benefit. > > b) How is consistency checking to be done? Related, what happens > > when a runtime switch introduces a dependency that then requires a > > non-runtime rebuild of the original package? > > flag needs to be dropped from IUSE_RUNTIME, so the rebuild would > occur. Uh, you're requiring ebuilds to ensure consistency of every possible configuration of the entire tree? > > c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( > > >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is > > installed and flag is off? From experience, quite a few places > > where you'd want to use suggestions will break if their suggested > > package is installed but doesn't meet version or use requirements. > > Use flag deps are dealt with identically to the way they are now. the > only difference , again, is that the package doesn't get re-emerged. > The VDB would still update imo as if the package did get re-emerged > (ie: USE and RDEPEND would update), to handle the use flag change > info in metadata but from what I can tell nothing else would need to > be touched. So such packages would just break at runtime? > > However, addressing these probably isn't enough, since this is > > just the things we had to think about for SDEPEND-style > > suggestions... There are likely to be things I've not thought of > > specific to this method that won't crop up until someone tries to > > deliver a decent implementation. This isn't a trivial feature. > > ..it really is. It piggy backs entirely on the current USE > implementation, and only skips triggering rebuilds because the > files-on-disk for a package don't need to change. It's only trivial if you don't try to do anything with it... - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBh2xgACgkQ96zL6DUtXhGyFwCfYnK+RGbE+bR1Y53t/X3P7UKb OW4An3fjTeXsXaksDTSAwf/yENunCGpC =bWvu -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 25 Sep 2012 18:02:39 +0200 hasufell wrote: > > Really? I thought it was pretty clearly. Yes, you need an > > implementation beforehand. > > Maybe you should read: > http://www.gentoo.org/proj/en/glep/glep-0001.html > > > "The reference implementation must be completed before any GLEP is > given status "Final", but it need not be completed before the GLEP is > accepted." > > This is not about some EAPI stuff, this is about getting it _accepted_ > not _implemented_. "Need not" does not mean "should not", and "completed" is not the same as "exists". In this case, any reasonable observer will conclude that for this particular problem, having a reasonable reference implementation and a bunch of ebuilds to play with before we spend any more time on discussion would be extremely helpful. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBh2SwACgkQ96zL6DUtXhGw5ACg06dBcpHZ3Zfq5bQL7I8x7WPT +WAAn1xpLtjISzwU1onKiZgG6jLpXV7J =j+q2 -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 17:00:07 +0100 Ciaran McCreesh wrote: > On Tue, 25 Sep 2012 12:43:00 -0300 > Alexis Ballier wrote: > > Could you please elaborate on what kind of problems may arise ? The > > proposal seems pretty simple and sane to me: PM only has to switch the > > useflags that are IUSE_RUNTIME in his installed packages db after > > installing the deps and without triggering a rebuild of said package. > > a) How do we provide a good user interface for it? It took an awful lot > of experimenting to get the exheres-0 suggestions user interface to be > good, and it requires quite a bit more information from the package > side than this proposal is providing. We want to avoid a REQUIRED_USE > here... Who is we? I believe REQUIRED_USE is one of the features which will be available thanks to staying compatible with USE flags instead of reinventing the wheel. > b) How is consistency checking to be done? Related, what happens when a > runtime switch introduces a dependency that then requires a non-runtime > rebuild of the original package? Then the package is rebuilt. Where's the problem? Handling of REQUIRED_USE is not perfectly user friendly but it works. > c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( >=cat/dep-2.1 ) > cases where cat/dep[-foo] or =cat/dep-2.0 is installed and flag is off? > From experience, quite a few places where you'd want to use suggestions > will break if their suggested package is installed but doesn't meet > version or use requirements. Er, you mean how to deal with an optional dependency which is not enabled at all? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/12 12:00 PM, Ciaran McCreesh wrote: > On Tue, 25 Sep 2012 12:43:00 -0300 Alexis Ballier > wrote: >> Could you please elaborate on what kind of problems may arise ? >> The proposal seems pretty simple and sane to me: PM only has to >> switch the useflags that are IUSE_RUNTIME in his installed >> packages db after installing the deps and without triggering a >> rebuild of said package. > > a) How do we provide a good user interface for it? It took an awful > lot of experimenting to get the exheres-0 suggestions user > interface to be good, and it requires quite a bit more information > from the package side than this proposal is providing. We want to > avoid a REQUIRED_USE here... Standard USE flag interface. This doesn't need anything special. Why will a user care if the flag doesn't trigger a package rebuild? > > b) How is consistency checking to be done? Related, what happens > when a runtime switch introduces a dependency that then requires a > non-runtime rebuild of the original package? flag needs to be dropped from IUSE_RUNTIME, so the rebuild would occur. > c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( > >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is > installed and flag is off? From experience, quite a few places > where you'd want to use suggestions will break if their suggested > package is installed but doesn't meet version or use requirements. Use flag deps are dealt with identically to the way they are now. the only difference , again, is that the package doesn't get re-emerged. The VDB would still update imo as if the package did get re-emerged (ie: USE and RDEPEND would update), to handle the use flag change info in metadata but from what I can tell nothing else would need to be touched. > > However, addressing these probably isn't enough, since this is > just the things we had to think about for SDEPEND-style > suggestions... There are likely to be things I've not thought of > specific to this method that won't crop up until someone tries to > deliver a decent implementation. This isn't a trivial feature. > ..it really is. It piggy backs entirely on the current USE implementation, and only skips triggering rebuilds because the files-on-disk for a package don't need to change. Now, I do realize that the potential for abuse here is large, and it will be up to dev's to ensure that these use flags (or groups of use flag conditions) added to IUSE_RUNTIME will not result in any files-changed-on-disk. However that to me doesn't seem to be a good enough reason to exclude it from a future EAPI. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBh2YkACgkQ2ugaI38ACPCrzwD/YhavLfXOjjpivCDZ5gbRFI9V /LBObF/haI2tMZ2CN4cA+wYBxFH1S2Az6zpSLLfAxWnDtPTe22wHb4nMUZ43uIV3 =r8ld -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 05:57 PM, Fabian Groffen wrote: > > I guess nothing is preventing them from reviewing it. However, > it's just a waste of time if you're just asking those guys to > review the GLEP, isn't it? > > That's what the GLEP workflow states, no? It's currently not accepted. On 09/25/2012 05:23 PM, Ciaran McCreesh wrote: > > Really? I thought it was pretty clearly. Yes, you need an > implementation beforehand. > Maybe you should read: http://www.gentoo.org/proj/en/glep/glep-0001.html "The reference implementation must be completed before any GLEP is given status "Final", but it need not be completed before the GLEP is accepted." This is not about some EAPI stuff, this is about getting it _accepted_ not _implemented_. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQYdWfAAoJEFpvPKfnPDWzjjIH/218/i8cD6jzdTOFskLQr8O8 PxOZAPDsRxKz9sVBLcN5I01RRATnr/xbhcomDa+/rLGP8Zz1ljk7mEwaXhXGg6fN l/lV0I62cjfWx1OJj9nqgq847TLLw1w+TKM/jfDvu2VXtMwBqiyg1U7+CeN7RWVH YdFOzKi3lJ1zH5oryT98htr6s+hceFie4JERlveODQn56vGG45c5c9vM0x7xxDce d+7lRozoEwp4AJA70zNskpEojYrJpBJNES/dt7GYO/Rt+sIqac4S8tUvNV3ro2a9 LV+Lr+qLvughdLtpewt95U63zeQJvfVbGIGwRlAaaUWYEI1IlOED6X25Zv3rQXo= =yexa -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 12:43:00 -0300 Alexis Ballier wrote: > Could you please elaborate on what kind of problems may arise ? The > proposal seems pretty simple and sane to me: PM only has to switch the > useflags that are IUSE_RUNTIME in his installed packages db after > installing the deps and without triggering a rebuild of said package. a) How do we provide a good user interface for it? It took an awful lot of experimenting to get the exheres-0 suggestions user interface to be good, and it requires quite a bit more information from the package side than this proposal is providing. We want to avoid a REQUIRED_USE here... b) How is consistency checking to be done? Related, what happens when a runtime switch introduces a dependency that then requires a non-runtime rebuild of the original package? c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is installed and flag is off? From experience, quite a few places where you'd want to use suggestions will break if their suggested package is installed but doesn't meet version or use requirements. However, addressing these probably isn't enough, since this is just the things we had to think about for SDEPEND-style suggestions... There are likely to be things I've not thought of specific to this method that won't crop up until someone tries to deliver a decent implementation. This isn't a trivial feature. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 25-09-2012 17:43:46 +0200, hasufell wrote: > > That doesn't prevent him from talking from past experiences and giving > > his opinion. Council is free to ignore his request also. > > Yeah, I thank him for that, but the time for user opinions has passed. I > am asking what is preventing the _council_ from reviewing this or why > the _author_ of that GLEP hasn't requested it for the next council meeting. I guess nothing is preventing them from reviewing it. However, it's just a waste of time if you're just asking those guys to review the GLEP, isn't it? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 09/25/2012 05:36 PM, Alexis Ballier wrote: > On Tue, 25 Sep 2012 17:30:07 +0200 > hasufell wrote: > >> On 09/25/2012 05:25 PM, Alexis Ballier wrote: >>> On Tue, 25 Sep 2012 17:17:07 +0200 >>> hasufell wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: > On Tue, 25 Sep 2012 17:04:55 +0200 hasufell > wrote: >> Do we need an implementation beforehand? Afaik zac said that the >> implementation would not be very complicated, so why not vote on >> this now/soon? > > Well we can't really compare it to SDEPEND (which is implemented > in Paludis, for kdebuild-1 and exheres-0) without at least a > half-arsed implementation. > > Also, speaking as someone who *has* implemented this kind of > thing, I have extreme doubts as to the viability of the proposal. > So I'd be extremely wary of voting in favour of it until we've > been able to have a play with an implementation. > sorry? I don't see an answers to any of my questions. >>> >>> he wants an implementation beforehand :) >>> >> >> Is he a council member? >> > > That doesn't prevent him from talking from past experiences and giving > his opinion. Council is free to ignore his request also. > Yeah, I thank him for that, but the time for user opinions has passed. I am asking what is preventing the _council_ from reviewing this or why the _author_ of that GLEP hasn't requested it for the next council meeting.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 16:10:56 +0100 Ciaran McCreesh wrote: > Also, speaking as someone who *has* implemented this kind of thing, I > have extreme doubts as to the viability of the proposal. So I'd be > extremely wary of voting in favour of it until we've been able to have > a play with an implementation. Could you please elaborate on what kind of problems may arise ? The proposal seems pretty simple and sane to me: PM only has to switch the useflags that are IUSE_RUNTIME in his installed packages db after installing the deps and without triggering a rebuild of said package.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 17:30:07 +0200 hasufell wrote: > On 09/25/2012 05:25 PM, Alexis Ballier wrote: > > On Tue, 25 Sep 2012 17:17:07 +0200 > > hasufell wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: > >>> On Tue, 25 Sep 2012 17:04:55 +0200 hasufell > >>> wrote: > Do we need an implementation beforehand? Afaik zac said that the > implementation would not be very complicated, so why not vote on > this now/soon? > >>> > >>> Well we can't really compare it to SDEPEND (which is implemented > >>> in Paludis, for kdebuild-1 and exheres-0) without at least a > >>> half-arsed implementation. > >>> > >>> Also, speaking as someone who *has* implemented this kind of > >>> thing, I have extreme doubts as to the viability of the proposal. > >>> So I'd be extremely wary of voting in favour of it until we've > >>> been able to have a play with an implementation. > >>> > >> > >> sorry? > >> > >> I don't see an answers to any of my questions. > > > > he wants an implementation beforehand :) > > > > Is he a council member? > That doesn't prevent him from talking from past experiences and giving his opinion. Council is free to ignore his request also.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 09/25/2012 05:25 PM, Alexis Ballier wrote: > On Tue, 25 Sep 2012 17:17:07 +0200 > hasufell wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: >>> On Tue, 25 Sep 2012 17:04:55 +0200 hasufell >>> wrote: Do we need an implementation beforehand? Afaik zac said that the implementation would not be very complicated, so why not vote on this now/soon? >>> >>> Well we can't really compare it to SDEPEND (which is implemented >>> in Paludis, for kdebuild-1 and exheres-0) without at least a >>> half-arsed implementation. >>> >>> Also, speaking as someone who *has* implemented this kind of thing, >>> I have extreme doubts as to the viability of the proposal. So I'd >>> be extremely wary of voting in favour of it until we've been able >>> to have a play with an implementation. >>> >> >> sorry? >> >> I don't see an answers to any of my questions. > > he wants an implementation beforehand :) > Is he a council member?
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 25 Sep 2012 17:17:07 +0200 hasufell wrote: > On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: > > On Tue, 25 Sep 2012 17:04:55 +0200 hasufell > > wrote: > >> Do we need an implementation beforehand? Afaik zac said that the > >> implementation would not be very complicated, so why not vote on > >> this now/soon? > > > > Well we can't really compare it to SDEPEND (which is implemented > > in Paludis, for kdebuild-1 and exheres-0) without at least a > > half-arsed implementation. > > > > Also, speaking as someone who *has* implemented this kind of thing, > > I have extreme doubts as to the viability of the proposal. So I'd > > be extremely wary of voting in favour of it until we've been able > > to have a play with an implementation. > > sorry? > > I don't see an answers to any of my questions. Really? I thought it was pretty clearly. Yes, you need an implementation beforehand. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBhzH4ACgkQ96zL6DUtXhHT2gCgtDFTdPkQ6X6jCkFzOIaqY+O7 uFQAnRnsznezzmSBha09MrCkRy1/3LZc =ouSd -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 25 Sep 2012 17:17:07 +0200 hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: > > On Tue, 25 Sep 2012 17:04:55 +0200 hasufell > > wrote: > >> Do we need an implementation beforehand? Afaik zac said that the > >> implementation would not be very complicated, so why not vote on > >> this now/soon? > > > > Well we can't really compare it to SDEPEND (which is implemented > > in Paludis, for kdebuild-1 and exheres-0) without at least a > > half-arsed implementation. > > > > Also, speaking as someone who *has* implemented this kind of thing, > > I have extreme doubts as to the viability of the proposal. So I'd > > be extremely wary of voting in favour of it until we've been able > > to have a play with an implementation. > > > > sorry? > > I don't see an answers to any of my questions. he wants an implementation beforehand :)
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2012 05:10 PM, Ciaran McCreesh wrote: > On Tue, 25 Sep 2012 17:04:55 +0200 hasufell > wrote: >> Do we need an implementation beforehand? Afaik zac said that the >> implementation would not be very complicated, so why not vote on >> this now/soon? > > Well we can't really compare it to SDEPEND (which is implemented > in Paludis, for kdebuild-1 and exheres-0) without at least a > half-arsed implementation. > > Also, speaking as someone who *has* implemented this kind of thing, > I have extreme doubts as to the viability of the proposal. So I'd > be extremely wary of voting in favour of it until we've been able > to have a play with an implementation. > sorry? I don't see an answers to any of my questions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQYcrzAAoJEFpvPKfnPDWztIwH/jXV53rVzF4dAImZbOb/zkD1 MU8JfWnYLirERryoix6lhtvMKlSxSCthU+M0wmKYdQ/Rwo5bqkRrgeSgfLg5xQo+ wn9k6YhiU6a0pWNTpG6WUZM9n6vwXYiqBwTX2QAedaPMCw/SbxQeSeF4bq0XNrRC jmwUXKO3LhhQDREuSFXg55LqBbx9NeFvoPxUlqOf7lPl0jXlbu6B0pR5MpxEqysy IFqglzXMIrguk9u/UxY/Z3lDfDzA1zxI3zgDGUiZ5sVKMtqEg8iDNbdsr9K0Zg0H Qe6mbAFYj3V0Nb6lA6n2/54KjWzVKl9dGtzGQsjwyfu4IdbZNX3O5qi+4Y2CYck= =QaMz -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 25 Sep 2012 17:04:55 +0200 hasufell wrote: > Do we need an implementation beforehand? Afaik zac said that the > implementation would not be very complicated, so why not vote on this > now/soon? Well we can't really compare it to SDEPEND (which is implemented in Paludis, for kdebuild-1 and exheres-0) without at least a half-arsed implementation. Also, speaking as someone who *has* implemented this kind of thing, I have extreme doubts as to the viability of the proposal. So I'd be extremely wary of voting in favour of it until we've been able to have a play with an implementation. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBhyYMACgkQ96zL6DUtXhGPsQCeN6muE82mJOPm9aox2zd1r8p0 5scAn3JkHsHGqPkpBJNCH4Nb94zW7b5H =LMaV -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anything holding this back to be reviewed by the council in the near future? Do we need an implementation beforehand? Afaik zac said that the implementation would not be very complicated, so why not vote on this now/soon? mgorny? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQYcgXAAoJEFpvPKfnPDWzFEgH/RD7Lvl8Dp16KK+02F7L0y70 rEJ9Syo6lApIg4u6BjhMglHUd3pAZxGJ4VPtQpCdu5BL7cH7wAV3cZY+JF1j+YNV Qd+gkVfVGJZf/gklza4pSayZluOTx9iqKr6HzPfWSQi6ugEtPG+46hLD4fGu3yre z1ndQjZDKy28fbG5p4R4nRDgYWUKkmd981nF8qBLguXuHDw0K3a5Hqx2l+cLZnc9 yynNX02cYDb3qtRH7QoQczfMnAv0nDIfUdWebuHAUFqFuHgAkgws9JrzkscGrAfR /KFQICl4TAwN0zlW69monOO3oMzZRYMsJlfX79W4RXhEmCRobb+VOLWxu9svCRs= =Ff4b -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Fri, 22 Jun 2012 19:29:15 +0100
David Leverton wrote:
> Ian Stakenvicius wrote:
> > Technically it could, but the issue here would be what you are going
> > to do with a has_version check on an IUSE_RUNTIME dep -- the package
> > should do filesystem-identical installs no matter what status of
> > IUSE_RUNTIME flags, so whatever one would do with a has_version
> > check would have to not change any part of the build or
> > installation.
>
> In principle it would be used for more or less the same thing as it
> would in a dependency, i.e. check whether the runtime-only
> dependencies for that feature are satisfied - the difference being
> that the package can specify arbitrary if-yes and if-no behaviours,
> rather than just "fail the dependency resolution" or not. (Modulo
> the problem being discussed in this subthread, that a "no" answer
> isn't reliable.)
>
> For example, some tool used during the build might have a "slow" mode
> that always works, and a "fast" mode that requires some other program
> to be installed and that has to be requested explicitly. So the
> package that uses the tool might want to do something like
>
> src_compile() {
> if has_version dev-util/buildtool[fast]; then
> buildtool --fast
> else
> buildtool
> fi
> }
And that particular example should be perfectly valid, to be honest.
There is just a little risk that fast mode wouldn't be used when it
could.
Of course, it's quite unlikely that such an option was actually based
on runtime dep...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Marien Zwart wrote: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) There may be more than one version of docmangler, with a postscript flag with different effects (IUSE_RUNTIME or full IUSE, different dependencies). That means this kind of rewriting would have to be done based on the dependencies of the docmangler installed at the time this package gets built, which seems like entirely too much magic, and... To clarify, I meant rewrite the dep in docmangler itself, and not necessarily on disk in the VDB or wherever, just in memory when parsing it. But as I said, I don't like that idea anyway, I just mentioned it for completeness. b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) this seems generally impossible, as the same USE flag may be IUSE_RUNTIME in only some versions of docmangler. True. We could declare that in situations like that the developer just needs to be more careful, but then it's not that much better than c) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required I would be in favor of leaving this up to the writer of the coolapp ebuild, especially as if docmangler is currently using a "full" USE flag for postscript this is already currently broken. Well, in theory if it's a normal USE flag then disabling it should actively remove the Ghostscript support from docmangler, even if Ghostscript happens to be installed, but maybe it doesn't always work out that way.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Ian Stakenvicius wrote:
Technically it could, but the issue here would be what you are going
to do with a has_version check on an IUSE_RUNTIME dep -- the package
should do filesystem-identical installs no matter what status of
IUSE_RUNTIME flags, so whatever one would do with a has_version check
would have to not change any part of the build or installation.
In principle it would be used for more or less the same thing as it
would in a dependency, i.e. check whether the runtime-only dependencies
for that feature are satisfied - the difference being that the package
can specify arbitrary if-yes and if-no behaviours, rather than just
"fail the dependency resolution" or not. (Modulo the problem being
discussed in this subthread, that a "no" answer isn't reliable.)
For example, some tool used during the build might have a "slow" mode
that always works, and a "fast" mode that requires some other program to
be installed and that has to be requested explicitly. So the package
that uses the tool might want to do something like
src_compile() {
if has_version dev-util/buildtool[fast]; then
buildtool --fast
else
buildtool
fi
}
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On do, 2012-06-21 at 20:05 +0100, David Leverton wrote:
> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> should REQUIRED_USE be re-verified:
>
> a) for every dep resolution
> b) when the package is involved in the resolution for some other reason
> (not necessarily being reinstalled, just when the resolver has some
> reason to look at it)
> c) something else?
>
> I think b) should be sufficient (and probably easier to implement), but
> is there any reason why it wouldn't be?
I would still prefer for the resolver to not treat such packages
specially at all, and to just deal with USE flag changes explicitly the
same way they're dealt with for "normal" packages/flags, just skipping
the actual rebuild and reinstall steps (just updating the vdb). This
sidesteps problems like this one completely. If the package manager
folks think they can safely do something smarter here that might be
nice, but the feature still seems useful (in reducing the number of
silly rebuilds) and far easier to understand without such magic.
This also means things like has_version checks work exactly like they do
right now.
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of
> package B being disabled, but it's unlikely to be useful. To make this
> more concrete, a fictional but vaguely plausible example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for
> # PostScript support if available
> IUSE="postscript"
> IUSE_RUNTIME="postscript"
> DEPEND="app-text/poppler"
> RDEPEND="${DEPEND}
> postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc"
> # if Ghostscript is installed, docmangler uses it for both
> # PostScript and PDF files, but Ghostscript misrenders our PDFs
> DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that flag,
> but it wouldn't do much good because Ghostscript would still be
> installed. This doesn't happen with regular USE flags because (if the
> ebuild is written correctly) disabling the flag removes the feature even
> if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as
> postscript? ( app-text/ghostscript )
> !postscript? ( !app-text/ghostscript )
There may be more than one version of docmangler, with a postscript flag
with different effects (IUSE_RUNTIME or full IUSE, different
dependencies). That means this kind of rewriting would have to be done
based on the dependencies of the docmangler installed at the time this
package gets built, which seems like entirely too much magic, and...
> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in the
> dependencies of the package itself, as that could cause similar paradoxes)
this seems generally impossible, as the same USE flag may be
IUSE_RUNTIME in only some versions of docmangler.
> c) don't address it in the spec itself, and require people to manually
> write the dep in the blocker form if it's required
I would be in favor of leaving this up to the writer of the coolapp
ebuild, especially as if docmangler is currently using a "full" USE flag
for postscript this is already currently broken. It seems coolapp should
not be building the pdfs, or should be deleting them after they're
built, rather than forbidding the user from having a docmangler that can
create pdfs (as presumably not *all* generated pdfs are corrupt).
I really think this GLEP should be purely about reducing silly rebuilds
in packages where it makes sense to USE-depend on them with a flag set,
or where an already popular flag can be used to pull in some obvious
packages. I think something like "suggested" dependencies can be used to
solve a slightly different problem, and perhaps we could have those too,
but let's leave those for later.
--
Marien Zwart
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/06/12 12:48 AM, Zac Medico wrote: > On 06/21/2012 02:32 PM, David Leverton wrote: >> Michał Górny wrote: >>> But in the current form, the spec doesn't allow passing >>> IUSE_RUNTIME flags to has_version() so we're on the safe side >>> :P. >> >> True. Do we want to keep it that restrictive? > > Shouldn't has_version allow any atom that would be allowed in > *DEPEND? Technically it could, but the issue here would be what you are going to do with a has_version check on an IUSE_RUNTIME dep -- the package should do filesystem-identical installs no matter what status of IUSE_RUNTIME flags, so whatever one would do with a has_version check would have to not change any part of the build or installation. I could see it being of use within pkg_configure(), though; ie, emerge - --config pkg should then be able to reliably set up default configs based on the runtime installs. However, that's the only place I can picture it being viable. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/kdmIACgkQ2ugaI38ACPBtsQEAs1Ak9JQnDFt4XuG/4ZfYGfH2 u92QpchtCGHhYbERx1wA/3AyghQuEv8WZ2iIfXoW9zWnelutj5fdqF4adSjMwf9x =0XPN -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Fri, Jun 22, 2012 at 8:45 AM, Zac Medico wrote: > On 06/21/2012 11:12 PM, Michał Górny wrote: >> On Thu, 21 Jun 2012 22:32:34 +0100 >> David Leverton wrote: >> >>> Michał Górny wrote: But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. >>> >>> True. Do we want to keep it that restrictive? >> >> I've added that to the spec but I'm not sure if we're not going too far >> with this. >> >> Now I'm seriously seeing downside of this solution and starting >> thinking about making them auto-enabled when deps are satisfied. > > The funny part is that this could recurse, if you call has_version > a[a-runtime-flag], which depends on b[b-runtime-flag], which depends on > c[c-runtime-flag] and so on... > > I suspect that we'd be better off with a less restrictive spec, and > without this "auto-enabled" thing. I deleted autouse in like 2006, please don't bring it back ;p -A > -- > Thanks, > Zac > >
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/21/2012 11:12 PM, Michał Górny wrote: > On Thu, 21 Jun 2012 22:32:34 +0100 > David Leverton wrote: > >> Michał Górny wrote: >>> But in the current form, the spec doesn't allow passing >>> IUSE_RUNTIME flags to has_version() so we're on the safe side :P. >> >> True. Do we want to keep it that restrictive? > > I've added that to the spec but I'm not sure if we're not going too far > with this. > > Now I'm seriously seeing downside of this solution and starting > thinking about making them auto-enabled when deps are satisfied. The funny part is that this could recurse, if you call has_version a[a-runtime-flag], which depends on b[b-runtime-flag], which depends on c[c-runtime-flag] and so on... I suspect that we'd be better off with a less restrictive spec, and without this "auto-enabled" thing. -- Thanks, Zac
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 22:32:34 +0100 David Leverton wrote: > Michał Górny wrote: > > No, of course not. Otherwise, every package manager run would > > practically require it to re-validate all packages in the tree > > (possibly not only installed ones). > > > > Package manager must ensure the flags are valid when package is > > in the graph. I would think of IUSE_RUNTIME as a last-step action > > where packages were in the graph for rebuild already but the > > rebuild is disabled as being unnecessary. > > That's what I thought, was just making sure we're on the same page. > > > No, the USE flag list in vdb may be updated every time the package > > gets into the graph with changed runtime flags. I don't consider > > that necessary, however. Just a nice backwards compatibility > > feature for other applications looking at vdb. > > 'K > > > Well, as I see it restricting is more of a policy than a technical > > requirement. > > As long as we're clear on which it is, and what restrictions if any > the PM can/should impose... > > > But in the current form, the spec doesn't allow passing > > IUSE_RUNTIME flags to has_version() so we're on the safe side :P. > > True. Do we want to keep it that restrictive? I've added that to the spec but I'm not sure if we're not going too far with this. Now I'm seriously seeing downside of this solution and starting thinking about making them auto-enabled when deps are satisfied. It doesn't prove any practical use except for the above case so it may be a better idea to just forbid it completely... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny wrote: > On Thu, 21 Jun 2012 08:30:24 +0100 > Ciaran McCreesh wrote: > >> On Thu, 21 Jun 2012 09:29:49 +0200 >> Michał Górny wrote: >> > On Wed, 20 Jun 2012 18:24:33 +0100 >> > Ciaran McCreesh wrote: >> > > On Wed, 20 Jun 2012 19:11:33 +0200 >> > > hasufell wrote: >> > > > On 06/20/2012 07:07 PM, Michał Górny wrote: >> > > > > Please read the rationale. Again. The whole thing. Three >> > > > > times. >> > > > >> > > > Please read my suggestions. Again. The whole thing. Three times. >> > > >> > > Can we all agree to just stop this and just restrict the arguing >> > > to being between SDEPEND and DEPENDENCIES? Cheers. >> > >> > You just volunteered to write portage patches. Cheers. >> >> Both were already implemented in Paludis, if you're looking for a >> reference implementation to try it out. There are also examples of >> use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I >> can give you a small patch to turn SDEPEND on for an EAPI if you like >> (it's just a one line addition to the EAPI definition file). > > Wait, did I just write to exherbo ml? No, don't think so. 'Implemented > in Paludis' doesn't work here. We're discussing Gentoo features, > and official package manager in Gentoo is portage. If you don't believe > me, check out the docs. > > -- > Best regards, > Michał Górny I would recommend the two of you step away from this thread and discussion for a day or two and come back to it with a fresh look at the suggestions and the code that's available and then we can move on getting this into an EAPI from there. -- Doug Goldstein
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/21/2012 02:32 PM, David Leverton wrote: > Michał Górny wrote: >> But in the current form, the spec doesn't allow passing >> IUSE_RUNTIME flags to has_version() so we're on the safe side :P. > > True. Do we want to keep it that restrictive? Shouldn't has_version allow any atom that would be allowed in *DEPEND? -- Thanks, Zac
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: No, of course not. Otherwise, every package manager run would practically require it to re-validate all packages in the tree (possibly not only installed ones). Package manager must ensure the flags are valid when package is in the graph. I would think of IUSE_RUNTIME as a last-step action where packages were in the graph for rebuild already but the rebuild is disabled as being unnecessary. That's what I thought, was just making sure we're on the same page. No, the USE flag list in vdb may be updated every time the package gets into the graph with changed runtime flags. I don't consider that necessary, however. Just a nice backwards compatibility feature for other applications looking at vdb. 'K Well, as I see it restricting is more of a policy than a technical requirement. As long as we're clear on which it is, and what restrictions if any the PM can/should impose... But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. True. Do we want to keep it that restrictive?
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 21:26:26 +0100 David Leverton wrote: > Michał Górny wrote: > > On Thu, 21 Jun 2012 20:05:46 +0100 > > David Leverton wrote: > >> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, > >> should REQUIRED_USE be re-verified: > >> > >> a) for every dep resolution > >> b) when the package is involved in the resolution for some other > >> reason (not necessarily being reinstalled, just when the resolver > >> has some reason to look at it) > >> c) something else? > > > > Well, I don't understand the difference between a) and b) in your > > case > > Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and > that I have it installed and then modify one of the flags it uses in > my configuration, but don't run any PM commands. Then suppose I > install a Gnome package. Normally installing a Gnome package > wouldn't require the PM to go anywhere near kde-meta, but being > strict about revalidating REQUIRED_USE would require it to look > through every installed package, just in case any have IUSE_RUNTIME > and REQUIRED_USE set, for every installation command. Is that > necessary? No, of course not. Otherwise, every package manager run would practically require it to re-validate all packages in the tree (possibly not only installed ones). Package manager must ensure the flags are valid when package is in the graph. I would think of IUSE_RUNTIME as a last-step action where packages were in the graph for rebuild already but the rebuild is disabled as being unnecessary. > > but the idea is that REQUIRED_USE should be re-verified if either > > enabled USE flag list or REQUIRED_USE changes. > > Would that mean the enabled USE flag list should be updated in the > VDB every time REQUIRED_USE is checked, even when the package isn't > being reinstalled? I think it would probably be easier to just > recheck REQUIRED_USE, without trying to figure out whether any of the > IUSE_RUNTIME flags were changed, it's just a question of how eager we > want to be. No, the USE flag list in vdb may be updated every time the package gets into the graph with changed runtime flags. I don't consider that necessary, however. Just a nice backwards compatibility feature for other applications looking at vdb. > >> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME > >> flag of package B being disabled, but it's unlikely to be useful. > >> To make this more concrete, a fictional but vaguely plausible > >> example: > > >> Possible solutions: > >> > >> a) automatically rewrite the dep as > >> postscript? ( app-text/ghostscript ) > >> !postscript? ( !app-text/ghostscript ) > >> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make > >> sense in that case to disallow them in !foo-style conditionals in > >> the dependencies of the package itself, as that could cause similar > >> paradoxes) > >> c) don't address it in the spec itself, and require people > >> to manually write the dep in the blocker form if it's required > >> d) something else? > > > Good observation. I think b) is the best solution since forced > > removal of random dependencies is a very bad idea (and misuse of > > blockers). > > One case that I forgot to mention before: if some package does > something like > > if has_version app-text/docmangler[postscript]; then > # ... > else > # ... > fi > > Here, again, the "else" branch can lead to incoherent results as it > can't assume that the postscript flag being disabled means > Ghostscript isn't installed, and this one can't be forbidden by > restricting the allowed dep forms. I think we'd have to just say > "don't do that then" Well, as I see it restricting is more of a policy than a technical requirement. But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: On Thu, 21 Jun 2012 20:05:46 +0100 David Leverton wrote: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? Well, I don't understand the difference between a) and b) in your case Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and that I have it installed and then modify one of the flags it uses in my configuration, but don't run any PM commands. Then suppose I install a Gnome package. Normally installing a Gnome package wouldn't require the PM to go anywhere near kde-meta, but being strict about revalidating REQUIRED_USE would require it to look through every installed package, just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every installation command. Is that necessary? > but the idea is that REQUIRED_USE should be re-verified if either > enabled USE flag list or REQUIRED_USE changes. Would that mean the enabled USE flag list should be updated in the VDB every time REQUIRED_USE is checked, even when the package isn't being reinstalled? I think it would probably be easier to just recheck REQUIRED_USE, without trying to figure out whether any of the IUSE_RUNTIME flags were changed, it's just a question of how eager we want to be. 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) >> c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? Good observation. I think b) is the best solution since forced removal of random dependencies is a very bad idea (and misuse of blockers). One case that I forgot to mention before: if some package does something like if has_version app-text/docmangler[postscript]; then # ... else # ... fi Here, again, the "else" branch can lead to incoherent results as it can't assume that the postscript flag being disabled means Ghostscript isn't installed, and this one can't be forbidden by restricting the allowed dep forms. I think we'd have to just say "don't do that then"
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton wrote:
> Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> should REQUIRED_USE be re-verified:
>
> a) for every dep resolution
> b) when the package is involved in the resolution for some other
> reason (not necessarily being reinstalled, just when the resolver has
> some reason to look at it)
> c) something else?
>
> I think b) should be sufficient (and probably easier to implement),
> but is there any reason why it wouldn't be?
Well, I don't understand the difference between a) and b) in your case
but the idea is that REQUIRED_USE should be re-verified if either
enabled USE flag list or REQUIRED_USE changes.
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
> of package B being disabled, but it's unlikely to be useful. To make
> this more concrete, a fictional but vaguely plausible example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for
> # PostScript support if available
> IUSE="postscript"
> IUSE_RUNTIME="postscript"
> DEPEND="app-text/poppler"
> RDEPEND="${DEPEND}
> postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc"
> # if Ghostscript is installed, docmangler uses it for both
> # PostScript and PDF files, but Ghostscript misrenders our PDFs
> DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that
> flag, but it wouldn't do much good because Ghostscript would still be
> installed. This doesn't happen with regular USE flags because (if
> the ebuild is written correctly) disabling the flag removes the
> feature even if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as
> postscript? ( app-text/ghostscript )
> !postscript? ( !app-text/ghostscript )
> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in the
> dependencies of the package itself, as that could cause similar
> paradoxes) c) don't address it in the spec itself, and require people
> to manually write the dep in the blocker form if it's required
> d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less flexible
> and c) leaves a potential trap for the unwary. Any opinions?
Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21/06/12 03:05 PM, David Leverton wrote:
> Michał Górny wrote:
>> Hello,
>>
>> A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> [ Snip! ]
>
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME
> flag of package B being disabled, but it's unlikely to be useful.
> To make this more concrete, a fictional but vaguely plausible
> example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for #
> PostScript support if available IUSE="postscript"
> IUSE_RUNTIME="postscript" DEPEND="app-text/poppler"
> RDEPEND="${DEPEND} postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc" # if Ghostscript is installed, docmangler uses it for
> both # PostScript and PDF files, but Ghostscript misrenders our
> PDFs DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that
> flag, but it wouldn't do much good because Ghostscript would still
> be installed. This doesn't happen with regular USE flags because
> (if the ebuild is written correctly) disabling the flag removes the
> feature even if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as postscript? (
> app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b)
> forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in
> the dependencies of the package itself, as that could cause similar
> paradoxes) c) don't address it in the spec itself, and require
> people to manually write the dep in the blocker form if it's
> required d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less
> flexible and c) leaves a potential trap for the unwary. Any
> opinions?
>
I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the
tree and if docmangler is used but fails when ghostscript is installed
anyways, then the DEPEND should specify this regardless of whether the
'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript
is in the user's world file.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo
Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURybNLR8FIkT2
=jMZ4
-END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote:
Hello,
A simple solution to a program long-unsolved. In GLEP form.
Just a couple of minor points/nitpicks:
1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:
a) for every dep resolution
b) when the package is involved in the resolution for some other reason
(not necessarily being reinstalled, just when the resolver has some
reason to look at it)
c) something else?
I think b) should be sufficient (and probably easier to implement), but
is there any reason why it wouldn't be?
2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of
package B being disabled, but it's unlikely to be useful. To make this
more concrete, a fictional but vaguely plausible example:
app-text/docmangler:
# links to poppler to handle PDFs, and can use Ghostscript for
# PostScript support if available
IUSE="postscript"
IUSE_RUNTIME="postscript"
DEPEND="app-text/poppler"
RDEPEND="${DEPEND}
postscript? ( app-text/ghostscript )"
app-misc/coolapp:
IUSE="doc"
# if Ghostscript is installed, docmangler uses it for both
# PostScript and PDF files, but Ghostscript misrenders our PDFs
DEPEND="doc? ( app-text/docmangler[-postscript] )"
Here, the [-postscript] dep would force the user to disable that flag,
but it wouldn't do much good because Ghostscript would still be
installed. This doesn't happen with regular USE flags because (if the
ebuild is written correctly) disabling the flag removes the feature even
if its dependencies happen to be installed.
Possible solutions:
a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar paradoxes)
c) don't address it in the spec itself, and require people to manually
write the dep in the blocker form if it's required
d) something else?
a) is pretty icky IMHO, especially if the flag pulls in multiple
packages. I could live with either b) or c), but b) is less flexible
and c) leaves a potential trap for the unwary. Any opinions?
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 10:54:19 +0200 Michał Górny wrote: > > And since when was "Implemented in Portage" a requirement for an > > EAPI feature? > > Remember EAPI4 and features which had reference implementation not > in portage? Actually, yes, since that was "most of them". Nearly all of them got implemented quickly. Our policy on this has always been "ask Zac whether he thinks they're reasonably quick to implement". But you know this, so kindly keep your disruption to places where you're right. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 08:41:23 +0100 Ciaran McCreesh wrote: > On Thu, 21 Jun 2012 09:42:36 +0200 > Michał Górny wrote: > > > > You just volunteered to write portage patches. Cheers. > > > > > > Both were already implemented in Paludis, if you're looking for a > > > reference implementation to try it out. There are also examples of > > > use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in > > > Exherbo. I can give you a small patch to turn SDEPEND on for an > > > EAPI if you like (it's just a one line addition to the EAPI > > > definition file). > > > > Wait, did I just write to exherbo ml? No, don't think so. > > 'Implemented in Paludis' doesn't work here. We're discussing Gentoo > > features, and official package manager in Gentoo is portage. If you > > don't believe me, check out the docs. > > And since when was "Implemented in Portage" a requirement for an EAPI > feature? Remember EAPI4 and features which had reference implementation not in portage? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 09:42:36 +0200 Michał Górny wrote: > > > You just volunteered to write portage patches. Cheers. > > > > Both were already implemented in Paludis, if you're looking for a > > reference implementation to try it out. There are also examples of > > use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in > > Exherbo. I can give you a small patch to turn SDEPEND on for an > > EAPI if you like (it's just a one line addition to the EAPI > > definition file). > > Wait, did I just write to exherbo ml? No, don't think so. 'Implemented > in Paludis' doesn't work here. We're discussing Gentoo features, > and official package manager in Gentoo is portage. If you don't > believe me, check out the docs. And since when was "Implemented in Portage" a requirement for an EAPI feature? The "implementation" requirement is to avoid REQUIRED_USE-like screwups. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 08:30:24 +0100 Ciaran McCreesh wrote: > On Thu, 21 Jun 2012 09:29:49 +0200 > Michał Górny wrote: > > On Wed, 20 Jun 2012 18:24:33 +0100 > > Ciaran McCreesh wrote: > > > On Wed, 20 Jun 2012 19:11:33 +0200 > > > hasufell wrote: > > > > On 06/20/2012 07:07 PM, Michał Górny wrote: > > > > > Please read the rationale. Again. The whole thing. Three > > > > > times. > > > > > > > > Please read my suggestions. Again. The whole thing. Three times. > > > > > > Can we all agree to just stop this and just restrict the arguing > > > to being between SDEPEND and DEPENDENCIES? Cheers. > > > > You just volunteered to write portage patches. Cheers. > > Both were already implemented in Paludis, if you're looking for a > reference implementation to try it out. There are also examples of > use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I > can give you a small patch to turn SDEPEND on for an EAPI if you like > (it's just a one line addition to the EAPI definition file). Wait, did I just write to exherbo ml? No, don't think so. 'Implemented in Paludis' doesn't work here. We're discussing Gentoo features, and official package manager in Gentoo is portage. If you don't believe me, check out the docs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Thu, 21 Jun 2012 09:29:49 +0200 Michał Górny wrote: > On Wed, 20 Jun 2012 18:24:33 +0100 > Ciaran McCreesh wrote: > > On Wed, 20 Jun 2012 19:11:33 +0200 > > hasufell wrote: > > > On 06/20/2012 07:07 PM, Michał Górny wrote: > > > > Please read the rationale. Again. The whole thing. Three times. > > > > > > Please read my suggestions. Again. The whole thing. Three times. > > > > Can we all agree to just stop this and just restrict the arguing to > > being between SDEPEND and DEPENDENCIES? Cheers. > > You just volunteered to write portage patches. Cheers. Both were already implemented in Paludis, if you're looking for a reference implementation to try it out. There are also examples of use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I can give you a small patch to turn SDEPEND on for an EAPI if you like (it's just a one line addition to the EAPI definition file). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 19:11:33 +0200 > hasufell wrote: > > On 06/20/2012 07:07 PM, Michał Górny wrote: > > > Please read the rationale. Again. The whole thing. Three times. > > > > Please read my suggestions. Again. The whole thing. Three times. > > Can we all agree to just stop this and just restrict the arguing to > being between SDEPEND and DEPENDENCIES? Cheers. You just volunteered to write portage patches. Cheers. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh wrote: > Can we all agree to just stop this and just restrict the arguing to > being between SDEPEND and DEPENDENCIES? Cheers. I clearly favour going with SDEPEND now as this fits better what people are used to and the move to DEPENDENCIES is also a chance to clean up dep-specs after we added all quirks we need(*). Let's name GLEP 54 here which we hopefully can add to EAPI 6. (*) or for when we run out of special chars ;) signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 19:11:33 +0200 hasufell wrote: > On 06/20/2012 07:07 PM, Michał Górny wrote: > > Please read the rationale. Again. The whole thing. Three times. > > Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/20/2012 07:07 PM, Michał Górny wrote: > Please read the rationale. Again. The whole thing. Three times. > Please read my suggestions. Again. The whole thing. Three times.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:57:19 +0200 hasufell wrote: > >> 2. Afais useflags that are already in IUSE and used for build-time > >> stuff must not be used for IUSE_RUNTIME too. > >> This is a random rule IMO. I don't have many cases in mind where > >> this would be annoying (could think of "debug" enabling some > >> in-source switches and adding optional debug tools in RDEPEND. > >> Having one flag here would make it cleaner and tighter for the > >> user to interact with useflags.). > >> However... this is not a logical rule, rather a technical issue. If > >> there is a way to avoid this restriction that would be nice. > > > > I do not see where you are going with this. If it makes sense to > > turn on the build-time support for a feature without installing all > > the dependencies then the extra dependencies should go behind a > > separate USE flag (and that separate USE flag may depend on the USE > > flag controlling the build-time support using REQUIRED_USE). Or > > perhaps the additional dependencies should be in some new kind of > > "suggested" depend. > > I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE > blocks the emerge process and should only be used when there is a > technical (not logical) useflag correlation. > > Using a seperate USE flag just because the name is blocked means the > user has to look up another useflag and think about what it is for. > > But as I said... that is rather minor. I just don't like it either, > cause I feel it might annoy me in the future. > > What do you think about useflag expansion and seperating them in > make.conf like yngwin suggested: > > USE_RUNTIME="debug" -> will enable "runtime_debug" useflag for all > ebuilds USE="debug" -> will enable "debug" useflag for all ebuilds > > This would also solve point #1 somehow, cause you don't have to fear > that your dependency graph will grow just because you didn't examine > all newly introduced IUSE_RUNTIME flags. > > For people who want that stuff unconditionally they could do: > USE_RUNTIME="$USE" > > and never bother again with it. Please read the rationale. Again. The whole thing. Three times. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/20/2012 05:05 PM, Marien Zwart wrote: > On di, 2012-06-19 at 18:53 +0200, hasufell wrote: >> >> 1. Optional deps are SUGGESTIONS from the dev which he considered >> nice/good/sane at the time of writing the ebuild. Other people might >> totally disagree with those suggestions. >> As useflags in IUSE_RUNTIME can pick from global useflags as well or >> even set "+foo" the user might have a hard time to turn off things he >> does not want without turning them off for regular IUSE as well. > > I think we're not all agreeing on which problem is being solved here. I > see IUSE_RUNTIME as an improvement for packages that have a runtime > dependency on another package to provide a certain feature, but no way > of turning this feature off at build time. Examples of this kind of > dependency are executables or python imports, where the executable or > library being absent is dealt with at runtime. For such packages putting > the dependency behind a USE flag makes sense, and for other packages to > depend on the package with that USE flag set also makes sense. Makes sense to you or the developer who wrote the ebuild. I know the usecases of IUSE_RUNTIME, but you have to realize that people might _not_ want additional optional runtime dependencies turned on by useflags that are already in _make.conf_! IUSE_RUNTIME is technically not a seperate thing, cause they go all into IUSE and maintaining useflags might become way more complicated for some users/usecases than it used to be, because of this new feature and a lot more dependencies that are triggered by your USE="..." variable. Something like FEATURES="optional-deps" would simply enable people to have a minimum of dependencies and still be able to use global useflags _without_ micro-managing all of them per-package, cause some of them are in IUSE_RUNTIME and others not. >> 2. Afais useflags that are already in IUSE and used for build-time stuff >> must not be used for IUSE_RUNTIME too. >> This is a random rule IMO. I don't have many cases in mind where this >> would be annoying (could think of "debug" enabling some in-source >> switches and adding optional debug tools in RDEPEND. Having one flag >> here would make it cleaner and tighter for the user to interact with >> useflags.). >> However... this is not a logical rule, rather a technical issue. If >> there is a way to avoid this restriction that would be nice. > > I do not see where you are going with this. If it makes sense to turn on > the build-time support for a feature without installing all the > dependencies then the extra dependencies should go behind a separate USE > flag (and that separate USE flag may depend on the USE flag controlling > the build-time support using REQUIRED_USE). Or perhaps the additional > dependencies should be in some new kind of "suggested" depend. I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE blocks the emerge process and should only be used when there is a technical (not logical) useflag correlation. Using a seperate USE flag just because the name is blocked means the user has to look up another useflag and think about what it is for. But as I said... that is rather minor. I just don't like it either, cause I feel it might annoy me in the future. What do you think about useflag expansion and seperating them in make.conf like yngwin suggested: USE_RUNTIME="debug" -> will enable "runtime_debug" useflag for all ebuilds USE="debug" -> will enable "debug" useflag for all ebuilds This would also solve point #1 somehow, cause you don't have to fear that your dependency graph will grow just because you didn't examine all newly introduced IUSE_RUNTIME flags. For people who want that stuff unconditionally they could do: USE_RUNTIME="$USE" and never bother again with it. > >> 3. There are no unconditional optional deps possible. >> ssuominen had an example: >> "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb >> in x11-base/xorg-server" > > I do not see where you are going with this. Can you refer me to where > this suggestion was made? virtualx.eclass adds a hard dependency if the > test USE flag (or some other USE flag) is set, and no dependency if this > USE flag is not set. When would virtualx.eclass add an optional > dependency? > I hope ssuominen might explain more about this idea as I already requested.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On di, 2012-06-19 at 18:53 +0200, hasufell wrote: > On 06/17/2012 10:31 PM, Michał Górny wrote: > > Hello, > > > > A simple solution to a program long-unsolved. In GLEP form. > > > > Both attached and published as a gist: > > > > https://gist.github.com/2945569 > > > > (please note that github doesn't render GLEP headers correctly) > > > > As already stated I like this idea, because I already got some optional > dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. > > However I have a few objections: > > 1. Optional deps are SUGGESTIONS from the dev which he considered > nice/good/sane at the time of writing the ebuild. Other people might > totally disagree with those suggestions. > As useflags in IUSE_RUNTIME can pick from global useflags as well or > even set "+foo" the user might have a hard time to turn off things he > does not want without turning them off for regular IUSE as well. I think we're not all agreeing on which problem is being solved here. I see IUSE_RUNTIME as an improvement for packages that have a runtime dependency on another package to provide a certain feature, but no way of turning this feature off at build time. Examples of this kind of dependency are executables or python imports, where the executable or library being absent is dealt with at runtime. For such packages putting the dependency behind a USE flag makes sense, and for other packages to depend on the package with that USE flag set also makes sense. This already works today. However, if you originally built the package with the USE flag off, and now try to install something that depends on the package with the USE flag on, you force a rebuild. That's not so nice, as there's no change to the installed package at all: the rebuild is a waste of time. IUSE_RUNTIME allows the package manager to skip that rebuild, as it now knows it is unnecessary. What you are describing is more like "suggested" dependencies. Those may also be useful, but do not solve quite the same problem. I do not think they quite replace the USE flag-based approach described above, as it makes sense for other ebuilds to depend on "foo with support for feature blah" through the "blah" USE flag without all those other packages having to know which specific dependencies this adds to foo, or whether foo needs a rebuild to enable the feature or not. Also, even in packages in which IUSE_RUNTIME is used for something like "suggested" dependencies it is not terribly hard for the user to turn the USE flag off (package.use) and install the interesting bits by hand. > 2. Afais useflags that are already in IUSE and used for build-time stuff > must not be used for IUSE_RUNTIME too. > This is a random rule IMO. I don't have many cases in mind where this > would be annoying (could think of "debug" enabling some in-source > switches and adding optional debug tools in RDEPEND. Having one flag > here would make it cleaner and tighter for the user to interact with > useflags.). > However... this is not a logical rule, rather a technical issue. If > there is a way to avoid this restriction that would be nice. I do not see where you are going with this. If it makes sense to turn on the build-time support for a feature without installing all the dependencies then the extra dependencies should go behind a separate USE flag (and that separate USE flag may depend on the USE flag controlling the build-time support using REQUIRED_USE). Or perhaps the additional dependencies should be in some new kind of "suggested" depend. > 3. There are no unconditional optional deps possible. > ssuominen had an example: > "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb > in x11-base/xorg-server" I do not see where you are going with this. Can you refer me to where this suggestion was made? virtualx.eclass adds a hard dependency if the test USE flag (or some other USE flag) is set, and no dependency if this USE flag is not set. When would virtualx.eclass add an optional dependency? -- Marien Zwart
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/17/2012 10:31 PM, Michał Górny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > As already stated I like this idea, because I already got some optional dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. However I have a few objections: 1. Optional deps are SUGGESTIONS from the dev which he considered nice/good/sane at the time of writing the ebuild. Other people might totally disagree with those suggestions. As useflags in IUSE_RUNTIME can pick from global useflags as well or even set "+foo" the user might have a hard time to turn off things he does not want without turning them off for regular IUSE as well. Means: "foo" pulls in an optional dependency for package suckbar/gaybar, but it also pulls in build-time deps for nerdbar/geekbar The user has to figure out now what the useflag does for each package and micromanage useflags to maybe avoid undesired optional deps. FEATURES="optional-deps" would be one way to overcome this, so I can globally turn useflags in IUSE_RUNTIME off without those in regular IUSE. But that may cause problems with REQUIRED_USE then maybe, not sure. 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of "debug" enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. (There was one proposal about expanding useflags in IUSE_RUNTIME, but I have not thought far in that direction.) 3. There are no unconditional optional deps possible. ssuominen had an example: "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb in x11-base/xorg-server" and some things I forgot...
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/17/2012 10:31 PM, Michał Górny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > This looks very nice, imo.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 19 Jun 2012 10:43:47 +0200 Michał Górny wrote: > > > - being package-oriented rather than feature-oriented, > > > > No; use flags are our configuration space, and they turn on/off > > sections of the given pkgs graph. Your proposal relies on the same > > concept; bluntly, what you're proposing is just as 'package > > oriented'. > > > > Effectively, you can't dismiss SDEPEND/ODEPEND via changing the > > rules between your proposal and ODEPEND's proposal. Nice try > > though. :) > > USE flags can describe features, like USE=ssl, USE=html, USE=whatever. > The exherbo suggested dependencies just list the relevant packages. > > In other words, here you enable USE=html to get HTML output. With > SDEPEND, you would --take dev-python/somerandomhtmllibrary. Incorrect. Exherbo allows suggestions to be grouped, described and taken by feature. It's done via annotations (the same mechanism used to provide decent handling of blockers etc). Search for "group-name" in exheres-for-smarties for an example. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Mon, 18 Jun 2012 20:04:48 -0700 Brian Harring wrote: > On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote: > > 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE > >dependencies by other packages' ``DEPEND``, ``RDEPEND`` > >and ``PDEPEND`` variables. > > Unless I'm on crack, you're stating that essentially an optional use > flag (one you label 'runtime'), is able to be used transitively > during DEPEND. That's not particularly "here's some suggested pkgs > to install"- that's "rebuild the fucker for this changed DEPEND", > which is the existing situation. It could be used by another package. Let's say dev-util/foo is a documentation generator in Python. It has optional runtime dependencies for HTML output enabled via USE=html. If dev-libs/bar uses foo for HTML output during the build, it can DEPEND on dev-util/foo[html]. > > The remaining reused features include: > > > > - dependency syntax, > > If you invent new syntax, I'm going to be unhappy. KISS as it were. > > > - ability to use ``REQUIRED_USE``, USE dependencies, > > - ability to describe flags in `metadata.xml`, > > - global flag names (and descriptions). > > > > Alternative proposed solution involved creating additional > > ``SDEPEND`` variable. That proposition had the following > > disadvantages: > > > > - being package-oriented rather than feature-oriented, > > No; use flags are our configuration space, and they turn on/off > sections of the given pkgs graph. Your proposal relies on the same > concept; bluntly, what you're proposing is just as 'package oriented'. > > Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules > between your proposal and ODEPEND's proposal. Nice try though. :) USE flags can describe features, like USE=ssl, USE=html, USE=whatever. The exherbo suggested dependencies just list the relevant packages. In other words, here you enable USE=html to get HTML output. With SDEPEND, you would --take dev-python/somerandomhtmllibrary. > > - lack of ability to express multiple packages required by a single > > feature, > > Eh? SDEPEND="my_feature? ( pkg1 pkg 2 )" SDEPEND didn't involve USE flags. If it did, we're back to square one. > > - lack of ability to express cross-feature dependencies, > > Clarify. This is a wee bit too vague for responding to ;) REQUIRED_USE. You don't have USE flags, you can't do that. > > - lack of ability to describe features provided by enabled packages, > > metadata.xml's local use description already covers that; in your > proposal above you lock in on use flags for the controlling of it > (which, presumably you'll abuse to get descriptions of) yet claim > it's not possible for ODEPEND (better name than SDEPEND :P). It didn't use USE flags. > > - necessity of implementing a new user interface parts to control > > the dependencies, > > Um... This is bullshit. Your proposal above is going to require a > lot more implementation, documentation of how this all is supposed to > work, and user ededucation for the weird scenarios where things don't > behave as expected, or they don't understand why changing use flag X, > results in the PM pulling in new packages (acting akin to -N), while > changing flag Y doesn't, and only does so/rebuilds via -N. > > That's not one of those things we can easily summarize in a UI; not > unless we want to extraordinarily verbose. While ODEPEND requires additional --take option, a way to list all possible packages which could be taken, teaching users why they are listed yet not pulled, how to pull and unpull them. > > - lack of backwards compatibility. > > This is a bit of a stretch; to be clear, you're proposing that the > depgraph changes in subtle/nasty ways on the fly under your scheme, > and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find > new and subtle ways to blow up the packages involved (specifically to > expose differing behaviour). It does that already. See 'man emerge', --dynamic-deps. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > > -- > Best regards, > Micha?? G??rny > GLEP: XXX > Title: Optional runtime dependencies via runtime-switchable USE flags > Version: $Revision:$ > Last-Modified: $Date:$ > Author: Micha?? G??rny > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 17 Jun 2012 > Post-History: > > > Abstract > > > This GLEP addresses the issue of referencing optional runtime > dependencies in Gentoo packages and ebuilds. It does introduce > a concept of runtime-switchable USE flags to achieve that goal. > > > Motivation > == > > Optional runtime dependencies are often found in packages installing > various scripts (shell, python, perl). These are not strictly required > for the particular package to work but installing them enables > additional functionality. > > Unlike in compiled programs, enabling or disabling those features > (dependencies) does not affect the files installed by the package. > They can be installed and uninstalled independently of the package, > resulting in changes of functionality without a need to rebuild > the package. > > Currently such dependencies are usually expressed only through > ``pkg_postinst()`` messages. This forces user to manually install > the necessary dependencies, and uninstall them when they are no longer > necessary. > > Another solution is using regular USE flags. Those flags do not strictly > follow the principles of USE flags because they do not affect files > installed by the package and are not entirely effective to the package > (a disabled feature will still be available if necessary dependency is > installed). Additionally, it requires unnecessary rebuilds > of the package in order to change the dependencies. > > > Specification > = > > The ebuilds aiming to provide features enabled through optional runtime > dependencies should: > > 1. create regular USE flags for all those features, following >appropriate specifications for Gentoo ebuilds, and including >the flags in the ``IUSE`` variable; > 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE >flags related to optional runtime dependencies (without prefixes >related to IUSE defaults). > > Additionally, the ebuilds must obey the following rules: > > 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``, > 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``, >``PDEPEND`` and ``REQUIRED_USE`` variables, > 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase >functions, ``DEPEND`` or ``SRC_URI``, > 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE >dependencies by other packages' ``DEPEND``, ``RDEPEND`` >and ``PDEPEND`` variables. Unless I'm on crack, you're stating that essentially an optional use flag (one you label 'runtime'), is able to be used transitively during DEPEND. That's not particularly "here's some suggested pkgs to install"- that's "rebuild the fucker for this changed DEPEND", which is the existing situation. > The package manager should treat flags listed in ``IUSE_RUNTIME`` > as regular USE flags, except for the following: > > 1. the state of the flags must be re-evaluated each time the package >dependency graph is considered, > 2. enabling or disabling any of the flags must not involve rebuilding >the package, > 3. the flags may be listed in the visual output in a distinct way >to inform the user that they affect runtime dependencies only. > > > Rationale > = > > The proposed solution tries to solve the issue of handling runtime > dependencies while reusing the existing infrastructure. Most > importantly, users will be able to reuse the existing tools > and configuration files to enable and disable optional runtime > and build-time dependencies alike. > > The remaining reused features include: > > - dependency syntax, If you invent new syntax, I'm going to be unhappy. KISS as it were. > - ability to use ``REQUIRED_USE``, USE dependencies, > - ability to describe flags in `metadata.xml`, > - global flag names (and descriptions). > > Alternative proposed solution involved creating additional ``SDEPEND`` > variable. That proposition had the following disadvantages: > > - being package-oriented rather than feature-oriented, No; use flags are our configuration space, and they turn on/off sections of the given pkgs graph. Your proposal relies on the same concept; bluntly, what you're proposing is just as 'package oriented'. Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules between your proposal and ODEPEND's proposal. Nice try though. :) > - lack of ability to express multiple package
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, 17 Jun 2012 21:38:50 +0100 Ciaran McCreesh wrote: > On Sun, 17 Jun 2012 22:31:59 +0200 > Michał Górny wrote: > > A simple solution to a program long-unsolved. In GLEP form. > > > > Both attached and published as a gist: > > > > https://gist.github.com/2945569 > > Do you have an implementation we can play with? Not yet. But expect one in the next few days. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, 17 Jun 2012 22:31:59 +0200 Michał Górny wrote: > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 Do you have an implementation we can play with? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Hello, A simple solution to a program long-unsolved. In GLEP form. Both attached and published as a gist: https://gist.github.com/2945569 (please note that github doesn't render GLEP headers correctly) -- Best regards, Michał Górny GLEP: XXX Title: Optional runtime dependencies via runtime-switchable USE flags Version: $Revision:$ Last-Modified: $Date:$ Author: MichaÅ Górny Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17 Jun 2012 Post-History: Abstract This GLEP addresses the issue of referencing optional runtime dependencies in Gentoo packages and ebuilds. It does introduce a concept of runtime-switchable USE flags to achieve that goal. Motivation == Optional runtime dependencies are often found in packages installing various scripts (shell, python, perl). These are not strictly required for the particular package to work but installing them enables additional functionality. Unlike in compiled programs, enabling or disabling those features (dependencies) does not affect the files installed by the package. They can be installed and uninstalled independently of the package, resulting in changes of functionality without a need to rebuild the package. Currently such dependencies are usually expressed only through ``pkg_postinst()`` messages. This forces user to manually install the necessary dependencies, and uninstall them when they are no longer necessary. Another solution is using regular USE flags. Those flags do not strictly follow the principles of USE flags because they do not affect files installed by the package and are not entirely effective to the package (a disabled feature will still be available if necessary dependency is installed). Additionally, it requires unnecessary rebuilds of the package in order to change the dependencies. Specification = The ebuilds aiming to provide features enabled through optional runtime dependencies should: 1. create regular USE flags for all those features, following appropriate specifications for Gentoo ebuilds, and including the flags in the ``IUSE`` variable; 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE flags related to optional runtime dependencies (without prefixes related to IUSE defaults). Additionally, the ebuilds must obey the following rules: 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``, 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``, ``PDEPEND`` and ``REQUIRED_USE`` variables, 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase functions, ``DEPEND`` or ``SRC_URI``, 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE dependencies by other packages' ``DEPEND``, ``RDEPEND`` and ``PDEPEND`` variables. The package manager should treat flags listed in ``IUSE_RUNTIME`` as regular USE flags, except for the following: 1. the state of the flags must be re-evaluated each time the package dependency graph is considered, 2. enabling or disabling any of the flags must not involve rebuilding the package, 3. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. Rationale = The proposed solution tries to solve the issue of handling runtime dependencies while reusing the existing infrastructure. Most importantly, users will be able to reuse the existing tools and configuration files to enable and disable optional runtime and build-time dependencies alike. The remaining reused features include: - dependency syntax, - ability to use ``REQUIRED_USE``, USE dependencies, - ability to describe flags in `metadata.xml`, - global flag names (and descriptions). Alternative proposed solution involved creating additional ``SDEPEND`` variable. That proposition had the following disadvantages: - being package-oriented rather than feature-oriented, - lack of ability to express multiple packages required by a single feature, - lack of ability to express cross-feature dependencies, - lack of ability to describe features provided by enabled packages, - necessity of implementing a new user interface parts to control the dependencies, - lack of backwards compatibility. Backwards compatibility === Package managers not implementing this GLEP will consider the ``IUSE_RUNTIME`` variable as an irrelevant bash variable and treat runtime-switchable USE flags as regular USE flags. The dependency tree will still be consistent yet packages may be rebuilt unnecessarily. Copyright = This document has been placed in the public domain. signature.asc Description: PGP signature
