Re: [gentoo-dev] Addressing GLEP-62 itself
On Sat, Sep 29, 2012 at 11:55:22AM +0200, Micha?? G??rny wrote: On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. What kind of addressing? The user interaction works like usual -- portage lists a bunch of flags, some of them may have additional hammers or sickles to mean that they will not trigger the rebuild. Nothing more is required. What is even more important, there is nothing new to learn for the user. In fact, he doesn't need anything new from UI. He will just set the flag like he did 10 years ago. 1) REQUIRED_USE interaction. That's a rats nest, trust me on that one. If your proposal is to just to have people tweak, get yelled at by the pm, tweak, etc, well, on behalf of users, thanks a lot. 2) While hard to comment since your 'updated' glep wasn't fully updated- now is self inconsistent (minimally, trace backwards compatibility; fix it in full next time)... you're not exactly covering how this will go; best I can figure, you just want to shove yet another coloring (great for color blind people) or syntax markup on emerge -pv style output, somehow indicating runtime toggable or not; this is getting picked at because that display already is a crapfest and overloaded. 3) You're ignoring cycles here; specifically suggested dep based cycles that influence the originating node, and how that is represented- this isn't counting representing during --tree mode what is brought in where/when because of it. 4) Finally, and more damningly, you're ignoring apps like porthole. You need to think long/hard about how *exactly* porthole is going to indicate to users what optionals are there- more importantly, what those optionals induce/require (that's where it truly gets ugly and your lack of dep resolver knowledge, and unwillingness to do a patch and learn the basics there become infuriating); || () or blockers w/in suggested alone are going to make things painful. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... As others have said, we're not stacking it. Using it in eclasses is whacky and should be avoided. End of the story. It's your proposal there boss. That's a stupid decision, but as said, your proposal to run into the ground if you'd like. However. I suggest you actually document that in your proposal that it breaks from the stacking norm. Also, drop the backwards compatibility claim at the bottom. It was bullshit before, the fact I keep having to picking
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. What kind of addressing? The user interaction works like usual -- portage lists a bunch of flags, some of them may have additional hammers or sickles to mean that they will not trigger the rebuild. Nothing more is required. What is even more important, there is nothing new to learn for the user. In fact, he doesn't need anything new from UI. He will just set the flag like he did 10 years ago. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... As others have said, we're not stacking it. Using it in eclasses is whacky and should be avoided. End of the story. Pretty much, this needs an implementation, partial conversion of the tree to demonstrate it. Just to prove that fricking point; if you had tried implementing this, a full investigation of what's involved alone, you'd have spotted that the core of the proposal is based on a wrong assumption. Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. There's a footnote there, saying: The package manager has to ensure that all relevant information is stored in the installed package metadata. Frankly I don't fully buy that you were aware of this issue from the start of the proposal; the wording partially covers it however. Ddoesn't call it out, but via tha req it dumps it on the package manager developers heads to sort it- which already is the case. Binpkgs minimally weren't addressed which is why I still don't think this was actually spotted up front. We talked about it, don't you remember? That's why I have updated the spec and put the whole implementation details thing with special note what needs to be stored in metadata. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, Sep 26, 2012 at 07:25:11PM -0300, Alexis Ballier wrote: On Wed, 26 Sep 2012 14:02:57 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote: IUSE_RUNTIME is optional for PMs, why does the UI matter at all ? Also, the proposal doesn't assume flags are toggable at will, it assumes they are useflags and obey the same rules. I truly hate claims like this; it's optional, so who cares if it's whacky. Think through the proposal; for it to work reliably, it's not optional. Same issue I've been y'all over the head with, rendered/finalized vs raw/unfinalized deps being stored in the VDB. All managers have to write unfinalized if that proposal goes through, even if they don't support the optional toggling after the fact. Why? _Current_ PMs will rebuild the package. The point of this is just to give them a hint that they do not need to rebuild it. We already have an implementation actually: one that ignores the hint :) Bullshit. This is optional in the sense of embrace/extend 'optional'; if one PM takes up the new functionality, all have to switch to writing unfinalized deps to the VDB, and all have to switch to transfering that IUSE_RUNTIME crap to the VDB. If they don't, whatever sole/crappy PM that runs w/ this proposal will wind up forcing rebuilds on any packages merged by the PM's that don't do this optional glep. Thus rendering it nonoptional since it implicitly is reliant on all switching to the degrade *DEPEND writing that this proposal is reliant on. The blame game becomes well, you shouldn't use the PMs that don't do this *optional* thing. There in is the implicit lie of that 'optional' crap. Claiming other wise is ignoring reality; I called it embrace/extend because this is exactly how that shit goes- sure it's optional, 'cept you're forced to support it (even partially) else the whole degrades and that PM winds up getting blackballed or fragmentation occuring. As far as I'm concerned, any PMS intended proposal must not pull the 'should' or 'optional' crap; it has no place in a spec (spec's are supposed to be assertions after all). As for the UI... arguing but it's optional! doesn't give a blank check for the UI angle. What the plan, more colorization and a new char for emerge -vp? Because we're kind of running out of chars there... How is this relevant ? Um... dude... This proposal is about adding suggested/optional deps so people can inspect/select/enable them per package. You're asking how is the UI relevant in light of that. Just saying; it's kind of core to this whole damn thing, else we're just trying to add an optimization hack; either one runs a strong risk of my next response including a joke about elderberries and hamsters. ;) It's a simple enough request; one that wouldn't even need to be made if there was code backing this proposal; on a related note, hell yes I'm wary of having this dumped on manager authors heads and having to be told sort out the mess/make it so. So I'm asking y'all to at least put in an equivalent time investment doing a quick prototype. This isn't an unreasonable request, and has been the norm for most gleps for a long while. I guess people do not want to invest time in writing code for something doomed. This is one of the cases where tough fucking luck really/truly fits. If it's doomed, consider why it's doomed. I'm not requiring a prototype just because I'm a dick; I'm requiring a prototype because I fully expect since y'all won't listen to what people are telling you, trying to write the code will educate y'all to what we've been saying. This is ignoring that prototypes are bsaically the norm for proposals of this sort (both PMS and gleps)... meaning it's the standard, and y'all are trying to get this proposal special cased. Does it suck you can't just get what you want via writing a quick doc and arguing on an ml? At times, yes. If you believe it's worth it, you do the legwork. If the folks backing this can't be bothered to write a freaking patch, well, I think that's a pretty strong vote of no-confidence on the backers part. The original request was just to have it 'accepted' so that an implementation can start. If the implementation is good then make it final, otherwise amend or reject the glep. This isn't unreasonable either. Also known as rubber stamp it. And if it sucks, of course it's easy to roll that bad idea back? Right? If the idea was universally accepted and lacked issues, that may fly; that's not been the case. It cannot be stacked because y'all are trying to shove this in as an optional; unlike it's brother IUSE, which stacks. As for ons of others that don't stack; very few actually influence the package manager; ~14 roughly, minimally 5 of those stack (those that don't, basically aren't lists). So it's not stacked, nothing
Re: [gentoo-dev] Addressing GLEP-62 itself
On 09/27/2012 12:53 PM, Brian Harring wrote: Bullshit. This is optional in the sense of embrace/extend 'optional'; if one PM takes up the new functionality, all have to switch to writing unfinalized deps to the VDB, and all have to switch to transfering that IUSE_RUNTIME crap to the VDB. I think the proposal suddenly becomes a lot saner if it's done as an EAPI extension, the optional runtime deps and IUSE_RUNTIME conditionals are isolated in a new separate variable (perhaps SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE. Using a separate SRDEPEND variable means that the package manager only has to preserve USE conditionals in the vdb for that one variable. -- Thanks, Zac
Re: [gentoo-dev] Addressing GLEP-62 itself
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/09/12 04:13 PM, Zac Medico wrote: On 09/27/2012 12:53 PM, Brian Harring wrote: Bullshit. This is optional in the sense of embrace/extend 'optional'; if one PM takes up the new functionality, all have to switch to writing unfinalized deps to the VDB, and all have to switch to transfering that IUSE_RUNTIME crap to the VDB. I think the proposal suddenly becomes a lot saner if it's done as an EAPI extension, the optional runtime deps and IUSE_RUNTIME conditionals are isolated in a new separate variable (perhaps SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE. Using a separate SRDEPEND variable means that the package manager only has to preserve USE conditionals in the vdb for that one variable. Saner, perhaps, but that would also mean the feature would be more or less independent of the current USE handling within the PM. Mind you if it's easier to deal with in the PM then I guess piggy-backing on the current USE implementation isn't an advantage. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBkt0oACgkQ2ugaI38ACPAKtQEAgkIJJfyBV20VsKVL8/dPlKF9 B4+SnJGlA+daYTCjXvgA/jq7aNzN8Cuj/sE+S+VWCK5U50vtHX3CqhoeOitgf9Zl =G5Tc -END PGP SIGNATURE-
Re: [gentoo-dev] Addressing GLEP-62 itself
On 09/27/2012 01:30 PM, Ian Stakenvicius wrote: On 27/09/12 04:13 PM, Zac Medico wrote: On 09/27/2012 12:53 PM, Brian Harring wrote: Bullshit. This is optional in the sense of embrace/extend 'optional'; if one PM takes up the new functionality, all have to switch to writing unfinalized deps to the VDB, and all have to switch to transfering that IUSE_RUNTIME crap to the VDB. I think the proposal suddenly becomes a lot saner if it's done as an EAPI extension, the optional runtime deps and IUSE_RUNTIME conditionals are isolated in a new separate variable (perhaps SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE. Using a separate SRDEPEND variable means that the package manager only has to preserve USE conditionals in the vdb for that one variable. Saner, perhaps, but that would also mean the feature would be more or less independent of the current USE handling within the PM. Well, the package manager could still treat IUSE_RUNTIME flags as valid flags for things like USE deps in _other_ packages. So, they don't have to be entirely independent. The idea is just to limit the scope where those flags are allowed the package that declares the flags as runtime flags, so that those runtime flags are only allowed in SRDEPEND. Mind you if it's easier to deal with in the PM then I guess piggy-backing on the current USE implementation isn't an advantage. Part of my concern is not just the implementation details, but also being able to explain/document for communication purposes. If it's such a mess that it's difficult to communicate, then it sucks for everyone involved. -- Thanks, Zac
Re: [gentoo-dev] Addressing GLEP-62 itself
On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Pretty much, this needs an implementation, partial conversion of the tree to demonstrate it. Just to prove that fricking point; if you had tried implementing this, a full investigation of what's involved alone, you'd have spotted that the core of the proposal is based on a wrong assumption. Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. There's a footnote there, saying: The package manager has to ensure that all relevant information is stored in the installed package metadata. I expect, as a corollary to this, that a rebuild would be necessary if (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty (--newuse) or resulted in any flags that are in USE (--reinstall=changed-use). IMO this would be necessary to ensure the local ebuild copy and all related metadata for it gets updated in vdb. I think that's a common package manager logic and it's out of scope of the GLEP. Portage doesn't do physical updates last I saw- if it did, well, that's fairly dangerous. Only thing stored in the VDB is the ebuild and the environment dump, and the environment dump is what's ran from. You cannot sanely pick part the dump and try to intermix current ebuilds; rephrasing, I'll kick in the head anyone who tries that. What are you talking about? As far as I can see, we are talking here about *full rebuild*. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... Pretty much, this needs an implementation, partial conversion of the tree to demonstrate it. Just to prove that fricking point; if you had tried implementing this, a full investigation of what's involved alone, you'd have spotted that the core of the proposal is based on a wrong assumption. Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. There's a footnote there, saying: The package manager has to ensure that all relevant information is stored in the installed package metadata. Frankly I don't fully buy that you were aware of this issue from the start of the proposal; the wording partially covers it however. Ddoesn't call it out, but via tha req it dumps it on the package manager developers heads to sort it- which already is the case. Binpkgs minimally weren't addressed which is why I still don't think this was actually spotted up front. Were it, the performance impact should've been mentioned, and quantified; con's are part of a normal glep. Meaning.. wait for it... writing a prototype is required to get those stats. ;) Based on the above I do expect the reference implementation would alsoneed to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. I expect, as a corollary to this, that a rebuild would be necessary if (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty (--newuse) or resulted in any flags that are in USE (--reinstall=changed-use). IMO this would be necessary to ensure the local ebuild copy and all related metadata for it gets updated in vdb. I think that's a common package manager logic and it's out of scope of the GLEP. Portage doesn't do physical updates last I saw- if it did, well, that's fairly dangerous. Only thing stored in the VDB is the ebuild and the environment dump, and the environment dump is what's ran from. You cannot sanely pick part the dump and try to intermix current ebuilds; rephrasing, I'll kick in the head anyone who tries that. What are you talking about? As far as I can see, we are talking here about *full rebuild*. Added the full quote
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. IUSE_RUNTIME is optional for PMs, why does the UI matter at all ? Also, the proposal doesn't assume flags are toggable at will, it assumes they are useflags and obey the same rules. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... It can't be stacked and it's not wise to do so; it is a simple bash variable like tons of others in eclasses: Package managers not implementing this GLEP will consider the ``IUSE_RUNTIME`` variable as an irrelevant bash variable 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE flags related to optional runtime dependencies (without prefixes related to IUSE defaults). Treating bash variables as bash variables is rather the norm, stacking is the exception. As I understand it, your only objection here is that you want to see written 'IUSE_RUNTIME gets no special treatment' in the proposal ? A.
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote: On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. IUSE_RUNTIME is optional for PMs, why does the UI matter at all ? Also, the proposal doesn't assume flags are toggable at will, it assumes they are useflags and obey the same rules. I truly hate claims like this; it's optional, so who cares if it's whacky. Think through the proposal; for it to work reliably, it's not optional. Same issue I've been y'all over the head with, rendered/finalized vs raw/unfinalized deps being stored in the VDB. All managers have to write unfinalized if that proposal goes through, even if they don't support the optional toggling after the fact. As for the UI... arguing but it's optional! doesn't give a blank check for the UI angle. What the plan, more colorization and a new char for emerge -vp? Because we're kind of running out of chars there... It's a simple enough request; one that wouldn't even need to be made if there was code backing this proposal; on a related note, hell yes I'm wary of having this dumped on manager authors heads and having to be told sort out the mess/make it so. So I'm asking y'all to at least put in an equivalent time investment doing a quick prototype. This isn't an unreasonable request, and has been the norm for most gleps for a long while. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... It can't be stacked and it's not wise to do so; it is a simple bash variable like tons of others in eclasses: It cannot be stacked because y'all are trying to shove this in as an optional; unlike it's brother IUSE, which stacks. As for ons of others that don't stack; very few actually influence the package manager; ~14 roughly, minimally 5 of those stack (those that don't, basically aren't lists). Package managers not implementing this GLEP will consider the ``IUSE_RUNTIME`` variable as an irrelevant bash variable 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE flags related to optional runtime dependencies (without prefixes related to IUSE defaults). Treating bash variables as bash variables is rather the norm, stacking is the exception. As I understand it, your only objection here is that you want to see written 'IUSE_RUNTIME gets no special treatment' in the proposal ? My objection is punting it to the council till it's actually nailed down/sane; having them mark it accepted
Re: [gentoo-dev] Addressing GLEP-62 itself
On 09/26/2012 11:02 PM, Brian Harring wrote: So yes, I want it actually finalized. Bluntly; there's zero point having the council comment if it ain't finalized. I understand. We probably have to wait for it then. Meanwhile... is there an alternative approach?
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, 26 Sep 2012 14:02:57 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote: On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring ferri...@gmail.com wrote: On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 12:54:39 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. ^^^ This point still needs addressing. IUSE_RUNTIME is optional for PMs, why does the UI matter at all ? Also, the proposal doesn't assume flags are toggable at will, it assumes they are useflags and obey the same rules. I truly hate claims like this; it's optional, so who cares if it's whacky. Think through the proposal; for it to work reliably, it's not optional. Same issue I've been y'all over the head with, rendered/finalized vs raw/unfinalized deps being stored in the VDB. All managers have to write unfinalized if that proposal goes through, even if they don't support the optional toggling after the fact. Why? _Current_ PMs will rebuild the package. The point of this is just to give them a hint that they do not need to rebuild it. We already have an implementation actually: one that ignores the hint :) As for the UI... arguing but it's optional! doesn't give a blank check for the UI angle. What the plan, more colorization and a new char for emerge -vp? Because we're kind of running out of chars there... How is this relevant ? It's a simple enough request; one that wouldn't even need to be made if there was code backing this proposal; on a related note, hell yes I'm wary of having this dumped on manager authors heads and having to be told sort out the mess/make it so. So I'm asking y'all to at least put in an equivalent time investment doing a quick prototype. This isn't an unreasonable request, and has been the norm for most gleps for a long while. I guess people do not want to invest time in writing code for something doomed. The original request was just to have it 'accepted' so that an implementation can start. If the implementation is good then make it final, otherwise amend or reject the glep. This isn't unreasonable either. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. The proposal didn't cover eclasses at all. Is there a need to do so or are we chasing some kind of perfection based on filling all unused slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... It can't be stacked and it's not wise to do so; it is a simple bash variable like tons of others in eclasses: It cannot be stacked because y'all are trying to shove this in as an optional; unlike it's brother IUSE, which stacks. As for ons of others that don't stack; very few actually influence the package manager; ~14 roughly, minimally 5 of those stack (those that
[gentoo-dev] Addressing GLEP-62 itself
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since hasufell brought it up, and as I believe he's going to ask Council to approve it before moving forward with this proposal towards including it in an EAPI, I wanted to clarify some of the points mentioned: - --- Quote, GLEP-62 --- Specifications, paragraph 3: The package manager should treat flags listed in IUSE_RUNTIME as regular USE flags, except for the following: 1. enabling or disabling any of the flags must not involve rebuilding the package, 2. it should be possible for a package manager to change those flags on a installed package without using the original ebuild, 3. when queried on a installed package, the package manager must consider a particular flag enabled only if its dependencies are satisfied already, 4. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. #2 -- this would, if I'm understanding it properly, mean that the IUSE list and the IUSE_RUNTIME list in the 'original ebuild' (ie in vdb) would be ignored on an emerged package in favour of the ebuild(s) in the tree, right? I'm not so sure this is a good idea. IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild and one of those use flags that changed have been triggered or de-triggered I expect that the package should be rebuilt, to keep it consistent with current practices. IE2, shouldn't the original ebuild be what's used to trigger the skip-rebuild functionality, rather than the in-tree ebuild? #3 -- this seems to imply to me, that the state of a package's effective USE could be modified solely on the basis of a dependency existing or not and have nothing to do with what the flag was set to at emerge time. IE, *not* the state of USE in the vdb. I think this would also be a problem. In order to properly handle dependency resolution (which IMO we should do, because these are still USE flags) I think all use flag settings should still be honoured by the PM and related metadata in the vdb be updated for IUSE_RUNTIME flags identically to how it would be done if IUSE_RUNTIME wasn't set. Thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBh8fgACgkQ2ugaI38ACPAENwD/VUmHAIQxuMF8p6FHYLtPk7J+ Xmar9LA0pNPTme27BiEA/3mKSC4VVlUMAT8IWxBcGCFcIQAx8pfirqhx7tfc3TZl =4oUH -END PGP SIGNATURE-
Re: [gentoo-dev] Addressing GLEP-62 itself
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/12 02:03 PM, Ian Stakenvicius wrote: Since hasufell brought it up, and as I believe he's going to ask Council to approve it before moving forward with this proposal towards including it in an EAPI, I wanted to clarify some of the points mentioned: --- Quote, GLEP-62 --- Specifications, paragraph 3: The package manager should treat flags listed in IUSE_RUNTIME as regular USE flags, except for the following: 1. enabling or disabling any of the flags must not involve rebuilding the package, 2. it should be possible for a package manager to change those flags on a installed package without using the original ebuild, 3. when queried on a installed package, the package manager must consider a particular flag enabled only if its dependencies are satisfied already, 4. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. #2 -- this would, if I'm understanding it properly, mean that the IUSE list and the IUSE_RUNTIME list in the 'original ebuild' (ie in vdb) would be ignored on an emerged package in favour of the ebuild(s) in the tree, right? I'm not so sure this is a good idea. IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild and one of those use flags that changed have been triggered or de-triggered I expect that the package should be rebuilt, to keep it consistent with current practices. IE2, shouldn't the original ebuild be what's used to trigger the skip-rebuild functionality, rather than the in-tree ebuild? #3 -- this seems to imply to me, that the state of a package's effective USE could be modified solely on the basis of a dependency existing or not and have nothing to do with what the flag was set to at emerge time. IE, *not* the state of USE in the vdb. I think this would also be a problem. In order to properly handle dependency resolution (which IMO we should do, because these are still USE flags) I think all use flag settings should still be honoured by the PM and related metadata in the vdb be updated for IUSE_RUNTIME flags identically to how it would be done if IUSE_RUNTIME wasn't set. Thoughts? Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. I expect, as a corollary to this, that a rebuild would be necessary if (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty (--newuse) or resulted in any flags that are in USE (--reinstall=changed-use). IMO this would be necessary to ensure the local ebuild copy and all related metadata for it gets updated in vdb. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBh/EUACgkQ2ugaI38ACPAFfAD/UsYVQg6ZkwlsaWIafuFr0sqC 7IuvqIgroxNWJ/5XRS8BAJ+5awXZanZftOmFWRmDUAxOvPc8+J073dAn78N0CPdB =zKzg -END PGP SIGNATURE-
Re: [gentoo-dev] Addressing GLEP-62 itself
On Tue, 25 Sep 2012 14:03:36 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since hasufell brought it up, and as I believe he's going to ask Council to approve it before moving forward with this proposal towards including it in an EAPI, I wanted to clarify some of the points mentioned: - --- Quote, GLEP-62 --- Specifications, paragraph 3: The package manager should treat flags listed in IUSE_RUNTIME as regular USE flags, except for the following: 1. enabling or disabling any of the flags must not involve rebuilding the package, 2. it should be possible for a package manager to change those flags on a installed package without using the original ebuild, 3. when queried on a installed package, the package manager must consider a particular flag enabled only if its dependencies are satisfied already, 4. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. #2 -- this would, if I'm understanding it properly, mean that the IUSE list and the IUSE_RUNTIME list in the 'original ebuild' (ie in vdb) would be ignored on an emerged package in favour of the ebuild(s) in the tree, right? I'm not so sure this is a good idea. The exact opposite. The PM should use vdb whenever no non-IUSE_RUNTIME flags have changed in vdb and no other reasons have caused it to use the ebuild repository. IE, if IUSE and IUSE_RUNTIME have changed in the in-tree ebuild and one of those use flags that changed have been triggered or de-triggered I expect that the package should be rebuilt, to keep it consistent with current practices. If --newuse triggers that, the ebuild will be used. IE2, shouldn't the original ebuild be what's used to trigger the skip-rebuild functionality, rather than the in-tree ebuild? I already said that :). #3 -- this seems to imply to me, that the state of a package's effective USE could be modified solely on the basis of a dependency existing or not and have nothing to do with what the flag was set to at emerge time. IE, *not* the state of USE in the vdb. I think this would also be a problem. No, you're overestimating it. It just means that the package manager should first install the dependencies, and then update USE in vdb, and not the other way around. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing GLEP-62 itself
On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. I expect, as a corollary to this, that a rebuild would be necessary if (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty (--newuse) or resulted in any flags that are in USE (--reinstall=changed-use). IMO this would be necessary to ensure the local ebuild copy and all related metadata for it gets updated in vdb. I think that's a common package manager logic and it's out of scope of the GLEP. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing GLEP-62 itself
On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: On Tue, 25 Sep 2012 14:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Based on the above I do expect the reference implementation would also need to change. I expect, for instance, that the PM's metadata-handling would need to occur as normal even though none of the package's phase functions would run, that is, *DEPEND (realistically RDEPEND as that should be the only one affected here, maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage would not be re-emerging the package from the tree the original ebuild would remain. Yes, unless I'm missing something that's the intent. I will re-read and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. Pretty much, this needs an implementation, partial conversion of the tree to demonstrate it. Just to prove that fricking point; if you had tried implementing this, a full investigation of what's involved alone, you'd have spotted that the core of the proposal is based on a wrong assumption. Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. Literally, USE=-x RDEPEND=x? ( dev-util/diffball ), the RDEPEND in the vdb is going to be . The retort is meh, that's minor; the fact this was missed doesn't inspire confidence; further, aside from the fact that writing finalized deps to the VDB ie, an accurate form of the deps- they're locked at that point, a smart PM can take advantage of that to avoid reading USE/IUSE till it's needed. This has measurable speed impact; if in doubt, rebuild a tree without it- that little trick I came up with first in pkgcore and it works on two fronts; 1) parsing is quicker, less nodes/smaller tree, 2) a smart PM can lazy load the USE/IUSE for performance gain. This is why portage/pkgcore were intentionally modified to do this; paludis may do it, haven't looked. My views, if the council is sane they'll slap it back down stating prove it's a viable solution; regardless of my views of the proposal (that it's the wrong way to solve it), it's not ready for an actual vote since approving it without actually verifying it could work makes things fucktons worse. I expect, as a corollary to this, that a rebuild would be necessary if (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty (--newuse) or resulted in any flags that are in USE (--reinstall=changed-use). IMO this would be necessary to ensure the local ebuild copy and all related metadata for it gets updated in vdb. I think that's a common package manager logic and it's out of scope of the GLEP. Portage doesn't do physical updates last I saw- if it did, well, that's fairly dangerous. Only thing stored in the VDB is the ebuild and the environment dump, and the environment dump is what's ran from. You cannot sanely pick part the dump and try to intermix current ebuilds; rephrasing, I'll kick in the head anyone who tries that. We used to do that shit; it broke, frequently. Env saving took a long time to get landed across the board- doing what you're proposing the PM should do breaks those guarantess and is a step back on that front alone. Basically, not happening, if it is, a series of bugs need filing. What portage does is that if it sees an ebuild in the tree that matches, it uses the deps from the tree; that's wholy different from what you think is happening in the vdb. Additionally, portage is the only PM that does this; the rest of the PMs treat the vdb ebuild as a constant- without extreme care, or some form of insane deptree comparison, you can't just swap in what a new ebuild has and expect it to work in all cases. ~harring
