Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Sat, 16 Nov 2013 11:57:23 +0100 Thomas Sachau wrote: > >>> 2: multilib-portage > > > > I think this has been discussed multiple times, if I don't > > misremember, PMS team is not willing to accept it until the > > specification is done... and we are waiting for that for years > > probably because it includes a lot of changes (well, Tommy will > > know much more about this) > > Ever tried to write a formal spec in a foreing language? You weren't asked to write a formal spec. You were asked to provide enough information so that someone else could do that. > Creating multilib-portage was easier then this request Had you kept track of what changes you made and why you made them when writing multilib-portage, we'd not have this problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 17 Nov 2013 17:09:10 +0100 hasufell wrote: > multilib eclasses as a whole were a big failure, both for users > (enough examples given here) You mean those failures where they mix branches and thus cause blockers between the old and new approach? Those failures have nothing to do with multilib eclasses, but rather by not understanding Portage's complexity; it works for me and I don't see a problem, I don't mix. > for developers (cause it requires understanding the eclasses). Are you able to contribute anything without understanding any eclass? > You should keep working on the spec, so we might be able to remove > that crap some day. Maybe, maybe not; you are replacing complexity by other complexity, now the real question is rather where we want this complexity to be. Multilib eclasses make bugs explicit and thus easier to find and fix. Multilib Portage takes bugs away from the eclasses and ebuilds such that they sit in Portage; this can be an advantage or disadvantage depending on how you look at it, but it however does mean that this need continued maintenance after this feature has been added to Portage. With the lower Portage development activity, is that a viable option? - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJSiPBTAAoJEJWyH81tNOV9QzcH/jS0X0nSCZRhPXYbwRr6xuBg vD5XCOwAbNHsEVfTo8kPpscvXsej4DQvvsVDGtCJEXlhO7pS4n9ArTEeeihVtgBI hqycMrnr1cJ2IdT8KGNn+56WfgIQW9KP02gtZkfoClUzzT0kXr4zX1oVvHY7NLd6 CIFBIQHh4oUs1wHg7OkkrZeWzQJNTRs4Uws6FGIF4L3+durbvLdwmF1WN8YzayTe 6hHOWTEzAXVAeh+cnkhhaJyjmBlpUNqMNG4JZ5OO50vu18YbK5cPRvMdUws3Rsw4 NGFMaEna5JqMSUA5yevdDVzXtkZzqtZUymSFMxcm5Kt5oXPofo9zPIOh3/2tAXk= =n44F -END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2013 11:57 AM, Thomas Sachau wrote: > Pacho Ramos schrieb: >> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió: >>> Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot >>> napisał(a): >>> As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages >> >> This is the current option but has important drawbacks: - Each >> emul set contains a ton of packages, then, when a security issue >> arises in one of them, we need to release a new >> emul-linux-x86-... - It's built from stable tree, it can then >> cause inconsistencies when people run native lib from testing (I >> remember pulseaudio case) - If we would like to really follow >> stabilized packages, we would nearly need to generate a new set >> every week because likely some of the contained packages will be >> stabilized on x86 so often. - As they are a big set of packages, >> people need to install a lot of stuff they don't really need >> >> In summary -> they are completely unflexible, with the problems >> it cause >> 2: multilib-portage >> >> I think this has been discussed multiple times, if I don't >> misremember, PMS team is not willing to accept it until the >> specification is done... and we are waiting for that for years >> probably because it includes a lot of changes (well, Tommy will >> know much more about this) > > Ever tried to write a formal spec in a foreing language? Creating > multilib-portage was easier then this request > > Anyway, the new multilib eclasses had no entrance barrier, so have > been added and effectively everyone is forced to use them. > > Since i dont expect anyone to vote for a different solution in the > future, which would force all multilib related parts to be > rewritten, i stopped my work on the spec part. If anyone wants to > continue that road, i can hand over any pieces i already have. > > Instead i will simply prepare/maintain multilib-portage as a > portage-only package manager based multilib solution, which > requires no changes to ebuilds. This also keeps a choice for users, > who cant or dont want to convert all needed ebuilds to the new > multilib eclasses. > > multilib eclasses as a whole were a big failure, both for users (enough examples given here) and for developers (cause it requires understanding the eclasses). You should keep working on the spec, so we might be able to remove that crap some day. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSiOomAAoJEFpvPKfnPDWzTRUH/j5tWONLBh1bxCrsayrztYqn GbK7Fz8RBTnkoJhmYX8InKh8USEyCY9fkRcxWgF2rcF801u8hhFwpXEzf5kTISMb ctshmuyY5pS8e9IavyYY6VOTGmT2p9rxMpBVoDMn6Jf3hDwA2T/cY+W/QE1UGPF2 WVmdUAGFjPEaVJzMkgEgkCtoPhlqmPpHXrmhMKUvMNOtTdyNKSpqy+/ViUSZPp+J zkHg3UyO5ROF0OTgXJLFT4gx+yR85b8IHrBdcfoAXFaAw7AU1ycJuZ2zHDCgzcjC X4YTdSDoUAbxUpXf3cab13wRnudsGDUPfXD8lIb/20aPHnkKgjlHl+Otp3AnYco= =tTTR -END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Pacho Ramos schrieb: > El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió: >> Dnia 2013-11-15, o godz. 14:53:00 >> Ben de Groot napisał(a): >> >>> As I see it now, with respect to multilib, we have three competing >>> solutions, but not a clear direction which way we want to go as a >>> distro: >>> >>> 1: emul-* packages > > This is the current option but has important drawbacks: > - Each emul set contains a ton of packages, then, when a security issue > arises in one of them, we need to release a new emul-linux-x86-... > - It's built from stable tree, it can then cause inconsistencies when > people run native lib from testing (I remember pulseaudio case) > - If we would like to really follow stabilized packages, we would nearly > need to generate a new set every week because likely some of the > contained packages will be stabilized on x86 so often. > - As they are a big set of packages, people need to install a lot of > stuff they don't really need > > In summary -> they are completely unflexible, with the problems it cause > >>> 2: multilib-portage > > I think this has been discussed multiple times, if I don't misremember, > PMS team is not willing to accept it until the specification is done... > and we are waiting for that for years probably because it includes a lot > of changes (well, Tommy will know much more about this) Ever tried to write a formal spec in a foreing language? Creating multilib-portage was easier then this request Anyway, the new multilib eclasses had no entrance barrier, so have been added and effectively everyone is forced to use them. Since i dont expect anyone to vote for a different solution in the future, which would force all multilib related parts to be rewritten, i stopped my work on the spec part. If anyone wants to continue that road, i can hand over any pieces i already have. Instead i will simply prepare/maintain multilib-portage as a portage-only package manager based multilib solution, which requires no changes to ebuilds. This also keeps a choice for users, who cant or dont want to convert all needed ebuilds to the new multilib eclasses. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió: > Dnia 2013-11-15, o godz. 14:53:00 > Ben de Groot napisał(a): > > > As I see it now, with respect to multilib, we have three competing > > solutions, but not a clear direction which way we want to go as a > > distro: > > > > 1: emul-* packages This is the current option but has important drawbacks: - Each emul set contains a ton of packages, then, when a security issue arises in one of them, we need to release a new emul-linux-x86-... - It's built from stable tree, it can then cause inconsistencies when people run native lib from testing (I remember pulseaudio case) - If we would like to really follow stabilized packages, we would nearly need to generate a new set every week because likely some of the contained packages will be stabilized on x86 so often. - As they are a big set of packages, people need to install a lot of stuff they don't really need In summary -> they are completely unflexible, with the problems it cause > > 2: multilib-portage I think this has been discussed multiple times, if I don't misremember, PMS team is not willing to accept it until the specification is done... and we are waiting for that for years probably because it includes a lot of changes (well, Tommy will know much more about this) > > 3: multilib.eclass > > This is my preferred solution
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 23:39:34 +0100 Michał Górny wrote: > Dnia 2013-11-15, o godz. 14:53:00 > Ben de Groot napisał(a): > > > As I see it now, with respect to multilib, we have three competing > > solutions, but not a clear direction which way we want to go as a > > distro: > > > > 1: emul-* packages > > 2: multilib-portage > > 3: multilib.eclass > > > > I would like to vote for option 1, as it is the least intrusive and > > does what we need. If it is really felt we need a more complete > > solution, then my vote would be for 2, since 3 is too intrusive and > > more likely to break or complicate stuff for normal users. > > > > If you say council should take more of a leadership role, then maybe > > this issue can be decided by council and a clear direction be taken > > by the distro as a whole? Then those who oppose the choice made can > > either put up or shut up, and we can all work at implementing the > > chosen solution. > > And what does, say, a Council decision change? Sure, Council can > affect opinions of some developers and so on but this is something > that needs real work, not talking and deciding. Sure, you can convince > the developers that X is better than Y but you also need to find > someone who will actually work on X. > > And I think the actual work done by *different* people shows which > solution is most preferred by the community. This is not something > that judges whether it's the best one, but probably it'll the most > maintainable one. Think of bus factor. This is comparable to survival of the fittest; you can't just pick an animal and have it be a success in a circus, you'd need to careful to see which animal is fit for it and learn it all the tricks. Only then people will come, watch and come back later... (Cirque du Soleil thinks outside of the box and doesn't use animals) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 23:26:57 +0100 Peter Stuge wrote: > Tom Wijsman wrote: > > > portage should say, with as similar wording as possible: > > > > > > "If you want to emerge libXt with those USE flags then you'll also > > > have to set those same USE flags for libYt and libZt because libXt > > > DEPENDs on them." > > > > > > Bonus points: > > > > > > "Would you like me to set those USE flags for libYt and libZt for > > > you? [Y/n]" > > > > Which part of this warns the user that the user is about to run into > > something broken / experimental? We need to add that too, because > > it is not clear from the output that you suggest. And if we add > > that as well, it gets to be quite long; > > It gets one word longer: > > "If you want to emerge libXt with those experimental USE flags then > you'll also have to set those same USE flags for libYt and libZt > because libXt DEPENDs on them." By making it a single word its true meaning is hidden; broken or experimental are just two possible meanings, there are others (eg. security masks). I think we will want to be more explicit here. > > how would we condense that? > > If something is a bit complicated then a bit more verbosity can be > really good. Extra words and verbosity's relationship depends on which extra words and what verbosity that one aims to achieve; so, it might be possible to condense this without making a change in verbosity, or even add verbosity by reaching more with less output (in processable list form): emerge: there are no ebuilds built with USE flags to satisfy "x11-proto/kbproto[abi_x86_32]". (dependency required by "x11-libs/libXt-1.1.4" [ebuild]) (dependency required by "libXt" [argument]) because of default/linux/amd64/13.0/package.use.stable.mask:1: # Ian Stakenvicius (20 Sep 2013) # on behalf of gx86-multilib project # Mask abi_x86_32 on stable until emul-* packages are made # fully redundant and end-user experience in resolving # flag changes and blockages is generally smooth. # Please keep in sync with hardened/linux/amd64. x11-proto/kbproto abi_x86_32 Unmask at your own risk or set x11-libs/libXt[-abi_x86_32]. This is similar to the package.mask output. (Automatic config writing behavior would indeed be nice to have.) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot napisał(a): > As I see it now, with respect to multilib, we have three competing > solutions, but not a clear direction which way we want to go as a > distro: > > 1: emul-* packages > 2: multilib-portage > 3: multilib.eclass > > I would like to vote for option 1, as it is the least intrusive and > does what we need. If it is really felt we need a more complete > solution, then my vote would be for 2, since 3 is too intrusive and > more likely to break or complicate stuff for normal users. > > If you say council should take more of a leadership role, then maybe > this issue can be decided by council and a clear direction be taken by > the distro as a whole? Then those who oppose the choice made can > either put up or shut up, and we can all work at implementing the > chosen solution. And what does, say, a Council decision change? Sure, Council can affect opinions of some developers and so on but this is something that needs real work, not talking and deciding. Sure, you can convince the developers that X is better than Y but you also need to find someone who will actually work on X. And I think the actual work done by *different* people shows which solution is most preferred by the community. This is not something that judges whether it's the best one, but probably it'll the most maintainable one. Think of bus factor. About your list, let's first note that emul-linux are not dead. We're working on getting a replacement but we aren't dumping them yet and we're actively encouraging developers to use any-of deps to support both multilib packages and emul-linux. As you probably have seen, emul-linux even had an update recently. On the other hand, let's be honest -- emul-linux are basically single-handedly maintained by Pacho. I can't talk for him but if you really want to keep that supported long-term, you need to find people who are going to work on them actively. I don't know the exact number of people actively working on multilib-portage but I haven't seen any progress on getting all the formal stuff done. And remember that this particular idea requires much more work since it assumes the spec becoming part of immutable EAPI -- getting it all right, extensive testing, considering all the corner cases, etc. One thing I can tell is that gx86-multilib is getting the widest support of all the solutions. It has most active developers, most active helping users and some support from random developers that just maintain their packages. It requires less work on the formal side, and gets better testing for the simple reason that you need to do it per-package. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: > > portage should say, with as similar wording as possible: > > > > "If you want to emerge libXt with those USE flags then you'll also > > have to set those same USE flags for libYt and libZt because libXt > > DEPENDs on them." > > > > Bonus points: > > > > "Would you like me to set those USE flags for libYt and libZt for > > you? [Y/n]" > > Which part of this warns the user that the user is about to run into > something broken / experimental? We need to add that too, because it is > not clear from the output that you suggest. And if we add that as well, > it gets to be quite long; It gets one word longer: "If you want to emerge libXt with those experimental USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them." > how would we condense that? If something is a bit complicated then a bit more verbosity can be really good. //Peter pgpCEQB4bI4gC.pgp Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 22:57:06 +0100 Peter Stuge wrote: > Tom Wijsman wrote: > > I'm not sure if making broken (or experimental) things more easily > > available or a suggestion would be a good idea; people already have > > enough trouble as it is, adding more doesn't seem to be the right > > way. > > It's not about broken/experimental, it's about the logical > consequences of an explicit action taken by the user. > > The user must get feedback based on what they said that they wanted > to do, not based on what is experimental. > > Mentioning that something is experimental is an optional bonus, but > assuming that the user already knows that this is the case is OK too. The * in the USE flag list marks this. > portage should say, with as similar wording as possible: > > "If you want to emerge libXt with those USE flags then you'll also > have to set those same USE flags for libYt and libZt because libXt > DEPENDs on them." > > Bonus points: > > "Would you like me to set those USE flags for libYt and libZt for > you? [Y/n]" Which part of this warns the user that the user is about to run into something broken / experimental? We need to add that too, because it is not clear from the output that you suggest. And if we add that as well, it gets to be quite long; how would we condense that? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 13:45:29 -0800 Matt Turner wrote: > On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman > wrote: > > On Fri, 15 Nov 2013 13:21:53 -0800 > > Matt Turner wrote: > > > >> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman > >> wrote: > >> > On Fri, 15 Nov 2013 12:25:47 -0800 > >> > Matt Turner wrote: > >> > > >> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman > >> >> wrote: > >> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag > >> >> for kbproto but was attempting to emerge unstable (or unmasked > >> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that > >> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge > >> >> libXt: > >> >> > >> >> [...] > >> >> > >> >> emerge: there are no ebuilds built with USE flags to satisfy > >> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]". > >> >> !!! One of the following packages is required to complete your > >> >> request: > >> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) > >> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild]) > >> >> (dependency required by "libXt" [argument]) > >> >> > >> >> It suggests that I turn off abi_x86_32 for libXt rather than > >> >> telling me to turn the flag on for kbproto! > >> > > >> > Why should it literally suggest you to do something known to be > >> > broken? > >> > >> I don't know what you mean. kbproto[abi_x86_32] isn't known to be > >> broken. You're asking a really weird question based on some > >> implicit context that's not available to me. > > > > A mask implies something is broken (or experimental). > > Then to answer your previous question: it would suggest it [something > broken, according to you] because you've asked for something broken > that depends on it! Because a maintainer or achitecture team forgot to cover that case and didn't check on reverse dependencies, which is another case; but even in this case Portage handles well, as it suggests to step away from the brokenness. > >> I'm claiming in this example that attempting to emerge > >> libXt[abi_x86_32], portage should tell you that abi_x86_32 should > >> be set for kbproto, rather than telling you to unset abi_x86_32 > >> for libXt (which you're requesting to be emerged, damn it!). > > > > You have to be explicit when you want broken (or experimental) > > things; just emerging it isn't enough, taking a step further than > > that is. > > I'm explicitly saying that I want libXt with USE=abi_x86_32. > Suggesting that I turn it off is kind of ridiculous, don't you think? In your case, yes. In general, no; if you suggest to do this to anyone instead of just the small few that want it, it would encourage people to override what we mark as broken and that is a recipe for disaster. > This seems pretty clear cut. Are you just jerking me around now? For your case it could be made better, but as this very same output gets the eyes of people with other intentions; we can't just outright apply it that way and break systems, we have to satisfy most parties. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: > I'm not sure if making broken (or experimental) things more easily > available or a suggestion would be a good idea; people already have > enough trouble as it is, adding more doesn't seem to be the right way. It's not about broken/experimental, it's about the logical consequences of an explicit action taken by the user. The user must get feedback based on what they said that they wanted to do, not based on what is experimental. Mentioning that something is experimental is an optional bonus, but assuming that the user already knows that this is the case is OK too. portage should say, with as similar wording as possible: "If you want to emerge libXt with those USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them." Bonus points: "Would you like me to set those USE flags for libYt and libZt for you? [Y/n]" //Peter pgpeLULoOr_EM.pgp Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman wrote: > On Fri, 15 Nov 2013 13:21:53 -0800 > Matt Turner wrote: > >> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman >> wrote: >> > On Fri, 15 Nov 2013 12:25:47 -0800 >> > Matt Turner wrote: >> > >> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman >> >> wrote: >> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag >> >> for kbproto but was attempting to emerge unstable (or unmasked >> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that >> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt: >> >> >> >> [...] >> >> >> >> emerge: there are no ebuilds built with USE flags to satisfy >> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]". >> >> !!! One of the following packages is required to complete your >> >> request: >> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) >> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild]) >> >> (dependency required by "libXt" [argument]) >> >> >> >> It suggests that I turn off abi_x86_32 for libXt rather than >> >> telling me to turn the flag on for kbproto! >> > >> > Why should it literally suggest you to do something known to be >> > broken? >> >> I don't know what you mean. kbproto[abi_x86_32] isn't known to be >> broken. You're asking a really weird question based on some implicit >> context that's not available to me. > > A mask implies something is broken (or experimental). Then to answer your previous question: it would suggest it [something broken, according to you] because you've asked for something broken that depends on it! >> I'm claiming in this example that attempting to emerge >> libXt[abi_x86_32], portage should tell you that abi_x86_32 should be >> set for kbproto, rather than telling you to unset abi_x86_32 for libXt >> (which you're requesting to be emerged, damn it!). > > You have to be explicit when you want broken (or experimental) things; > just emerging it isn't enough, taking a step further than that is. I'm explicitly saying that I want libXt with USE=abi_x86_32. Suggesting that I turn it off is kind of ridiculous, don't you think? This seems pretty clear cut. Are you just jerking me around now?
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 13:21:53 -0800
Matt Turner wrote:
> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman
> wrote:
> > On Fri, 15 Nov 2013 12:25:47 -0800
> > Matt Turner wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
> >> wrote:
> >> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag
> >> for kbproto but was attempting to emerge unstable (or unmasked
> >> abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that
> >> abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt:
> >>
> >> [...]
> >>
> >> emerge: there are no ebuilds built with USE flags to satisfy
> >> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
> >> !!! One of the following packages is required to complete your
> >> request:
> >> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
> >> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
> >> (dependency required by "libXt" [argument])
> >>
> >> It suggests that I turn off abi_x86_32 for libXt rather than
> >> telling me to turn the flag on for kbproto!
> >
> > Why should it literally suggest you to do something known to be
> > broken?
>
> I don't know what you mean. kbproto[abi_x86_32] isn't known to be
> broken. You're asking a really weird question based on some implicit
> context that's not available to me.
A mask implies something is broken (or experimental).
> I'm claiming in this example that attempting to emerge
> libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
> set for kbproto, rather than telling you to unset abi_x86_32 for libXt
> (which you're requesting to be emerged, damn it!).
You have to be explicit when you want broken (or experimental) things;
just emerging it isn't enough, taking a step further than that is.
I'm not sure if making broken (or experimental) things more easily
available or a suggestion would be a good idea; people already have
enough trouble as it is, adding more doesn't seem to be the right way.
> > It is clear from the output how it wants the dependency to be; so,
> > if you want to do something different, you can and the output tells
> > enough.
> >
> > Due to the complexity of the dependency, you will need `man 5
> > ebuild` though; (-) means to assume it as disabled if it doesn't
> > exist.
> >
> >> Portage prints other things intelligently:
> >>
> >> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
> >>
> >> These are the packages that would be merged, in order:
> >>
> >> Calculating dependencies... done!
> >>
> >>
> >> [nomerge ] dev-python/py-1.4.13 USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)"
> >> [ebuild N ] dev-python/pytest-2.3.5 USE="{test} -doc"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 417 kB
> >> [ebuild N ] dev-python/py-1.4.13 USE="{test}"
> >> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> >> (-python3_3)" 185 kB
> >>
> >> Total: 2 packages (2 new), Size of downloads: 602 kB
> >>
> >> * Error: circular dependencies:
> >>
> >> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends
> >> on (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
> >> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
> >> merge) (buildtime)
> >>
> >> It might be possible to break this cycle
> >> by applying the following change:
> >> - dev-python/py-1.4.13 (Change USE: -test)
> >>
> >> Note that this change can be reverted, once the package has been
> >> installed.
> >
> > This is just like how you can't compile gcc without having compiled
> > gcc with another compiler first (or used a binpkg, or obtained from
> > stage3); thus, similarly, you can't test py without having pytest
> > first etc...
>
> I don't think you understood my intention for giving this example.
> Portage correctly figures out the proper solution and suggests it. I'm
> saying that this is a good thing.
Now the question is whether this is or isn't an opposite example;
because it might very well be intelligent, that doesn't mean that the
other example isn't intelligent. As we trying to make that clear, this
example doesn't really fit; so, I didn't assume it to be opposite.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 22:09:04 +0100 Peter Stuge wrote: > Tom Wijsman wrote: > > Does replacing this "explicit behavior" by "implicit behavior" make > > sense for the users in general? > > Please don't warp the words. Maybe I misunderstand, but it seems like > that's what you're doing. > > I'll try to clarify: > > With explicit I was refering to allowing manual setting and unsetting > of USE flags, keywords and masks. > > With implicit I was refering to those same things happening > automatically. USE flags set or unset automatically, keywords set or > unset automatically, masks set or unset automatically - as a result > of something or other. > > Any such automations significantly diminish the value of the explicit > knobs and are counter-intuitive. "implicit" in the context of this sub thread is it being present as part of another choice, whereas "explicit" makes it a separate choice. Currently the behavior is explicit because you have to break the dependency cycle yourself and decide how to, whereas making it implicit would solve it; in one or another particular way you'd be unaware of. > If someone is given a mechanism to control which USE flags are set or > unset then it's just stupid to go "around" those settings. This example was about a circular dependency, not about USE flags. > I understand the temptation to make things happen automatically for > ease of development, and that is perfectly fine as long as those > automations aren't exposed to users. And that's the question, it is the hard part of figuring it out... :) (To be clear: In the context of the sub thread answering the example.) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman wrote:
> On Fri, 15 Nov 2013 12:25:47 -0800
> Matt Turner wrote:
>
>> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
>> wrote:
>> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
>> kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
>> libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
>> unmerge kbproto and attempt to emerge libXt:
>>
>> [...]
>>
>> emerge: there are no ebuilds built with USE flags to satisfy
>> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
>> !!! One of the following packages is required to complete your
>> request:
>> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
>> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
>> (dependency required by "libXt" [argument])
>>
>> It suggests that I turn off abi_x86_32 for libXt rather than telling
>> me to turn the flag on for kbproto!
>
> Why should it literally suggest you to do something known to be broken?
I don't know what you mean. kbproto[abi_x86_32] isn't known to be
broken. You're asking a really weird question based on some implicit
context that's not available to me.
I'm claiming in this example that attempting to emerge
libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
set for kbproto, rather than telling you to unset abi_x86_32 for libXt
(which you're requesting to be emerged, damn it!).
> It is clear from the output how it wants the dependency to be; so, if
> you want to do something different, you can and the output tells enough.
>
> Due to the complexity of the dependency, you will need `man 5 ebuild`
> though; (-) means to assume it as disabled if it doesn't exist.
>
>> Portage prints other things intelligently:
>>
>> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>>
>> [nomerge ] dev-python/py-1.4.13 USE="{test}"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)"
>> [ebuild N ] dev-python/pytest-2.3.5 USE="{test} -doc"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)" 417 kB
>> [ebuild N ] dev-python/py-1.4.13 USE="{test}"
>> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
>> (-python3_3)" 185 kB
>>
>> Total: 2 packages (2 new), Size of downloads: 602 kB
>>
>> * Error: circular dependencies:
>>
>> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
>> (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
>> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
>> merge) (buildtime)
>>
>> It might be possible to break this cycle
>> by applying the following change:
>> - dev-python/py-1.4.13 (Change USE: -test)
>>
>> Note that this change can be reverted, once the package has been
>> installed.
>
> This is just like how you can't compile gcc without having compiled gcc
> with another compiler first (or used a binpkg, or obtained from stage3);
> thus, similarly, you can't test py without having pytest first etc...
I don't think you understood my intention for giving this example.
Portage correctly figures out the proper solution and suggests it. I'm
saying that this is a good thing.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: > Does replacing this "explicit behavior" by "implicit behavior" make > sense for the users in general? Please don't warp the words. Maybe I misunderstand, but it seems like that's what you're doing. I'll try to clarify: With explicit I was refering to allowing manual setting and unsetting of USE flags, keywords and masks. With implicit I was refering to those same things happening automatically. USE flags set or unset automatically, keywords set or unset automatically, masks set or unset automatically - as a result of something or other. Any such automations significantly diminish the value of the explicit knobs and are counter-intuitive. If someone is given a mechanism to control which USE flags are set or unset then it's just stupid to go "around" those settings. I understand the temptation to make things happen automatically for ease of development, and that is perfectly fine as long as those automations aren't exposed to users. //Peter pgpiM9GF5fyrB.pgp Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner wrote:
> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
> wrote:
> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
> kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
> libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
> unmerge kbproto and attempt to emerge libXt:
>
> [...]
>
> emerge: there are no ebuilds built with USE flags to satisfy
> "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
> !!! One of the following packages is required to complete your
> request:
> - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
> (dependency required by "x11-libs/libXt-1.1.4" [ebuild])
> (dependency required by "libXt" [argument])
>
> It suggests that I turn off abi_x86_32 for libXt rather than telling
> me to turn the flag on for kbproto!
Why should it literally suggest you to do something known to be broken?
It is clear from the output how it wants the dependency to be; so, if
you want to do something different, you can and the output tells enough.
Due to the complexity of the dependency, you will need `man 5 ebuild`
though; (-) means to assume it as disabled if it doesn't exist.
> Portage prints other things intelligently:
>
> mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
>
> [nomerge ] dev-python/py-1.4.13 USE="{test}"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)"
> [ebuild N ] dev-python/pytest-2.3.5 USE="{test} -doc"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)" 417 kB
> [ebuild N ] dev-python/py-1.4.13 USE="{test}"
> PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
> (-python3_3)" 185 kB
>
> Total: 2 packages (2 new), Size of downloads: 602 kB
>
> * Error: circular dependencies:
>
> (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
> (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
> (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
> merge) (buildtime)
>
> It might be possible to break this cycle
> by applying the following change:
> - dev-python/py-1.4.13 (Change USE: -test)
>
> Note that this change can be reverted, once the package has been
> installed.
This is just like how you can't compile gcc without having compiled gcc
with another compiler first (or used a binpkg, or obtained from stage3);
thus, similarly, you can't test py without having pytest first etc...
For example, emerging dev-java/icedtea without a Java compiler / runtime
present will show you the same behavior; and there are some other
circular dependencies present in the tree that behave similarly.
It's a problem that you can't really solve as far as I know; bugs are
often getting filed for it, but without a fix. One filed against
Portage is for example https://bugs.gentoo.org/show_bug.cgi?id=417675
but it hasn't received much attention; because well, I doubt if a proper
solution to this would be simple.
Workarounds mentioned are hacking up the vdb or changing --newuse.
Does replacing this "explicit behavior" by "implicit behavior" make
sense for the users in general? Does it make sense for those that just
want to test? Will people understand it if it were implicit behavior?
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800
> Matt Turner wrote:
>
>> There's a single problem. It can't enable abi_x86_32. Why didn't it
>> just say that?
>
> As per the full output, it does:
>
> !!! Enabling --newuse and --update might solve this conflict.
> !!! If not, it might help emerge to give a more specific suggestion.
>
> That together with ABI_X86="(64) (-32*) (-x32)" from the package line
> makes it clear that it is trying to change that USE flag. But as you
> haven't told emerge yet to do so, it doesn't; which makes it unable.
Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
unmerge kbproto and attempt to emerge libXt:
dynamic71 mattst88 # emerge libXt -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds built with USE flags to satisfy
"x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
!!! One of the following packages is required to complete your request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by "x11-libs/libXt-1.1.4" [ebuild])
(dependency required by "libXt" [argument])
It suggests that I turn off abi_x86_32 for libXt rather than telling
me to turn the flag on for kbproto!
Portage prints other things intelligently:
mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-python/py-1.4.13 USE="{test}"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)"
[ebuild N ] dev-python/pytest-2.3.5 USE="{test} -doc"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)" 417 kB
[ebuild N ] dev-python/py-1.4.13 USE="{test}"
PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)" 185 kB
Total: 2 packages (2 new), Size of downloads: 602 kB
* Error: circular dependencies:
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
(dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge) (buildtime)
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)
Note that this change can be reverted, once the package has been installed.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 21:10:41 +0100 Peter Stuge wrote: > Tom Wijsman wrote: > > !!! Enabling --newuse and --update might solve this conflict. > > !!! If not, it might help emerge to give a more specific suggestion. > > > > That together with ABI_X86="(64) (-32*) (-x32)" from the package > > line makes it clear that it is trying to change that USE flag. > > I disagree quite strongly with that statement. There is no clear > message at all about the situation. > > The problem is that the USE flag is "hidden" on the package line as > opposed to mentioned explicitly by portage. It's easy for software to > print meaningful output based on the data it has while it is awkward > for humans to scan lines and lines of output for parentheses with *s > and -s. Which is not the case here; as a single package is being emerged, the output is rather short. So, it is as clear as how much you read of it. The shortness of the output actually makes it much easier to scan. The other case would be `emerge -uDN @world` which gives a lot of output; but that case is different, as it wouldn't suggest the above. Now imaging if that long output was very much longer; the longness of that output, would be quite impossible to scan within the time one would process the normal `emerge -uDN @world` output. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: > !!! Enabling --newuse and --update might solve this conflict. > !!! If not, it might help emerge to give a more specific suggestion. > > That together with ABI_X86="(64) (-32*) (-x32)" from the package line > makes it clear that it is trying to change that USE flag. I disagree quite strongly with that statement. There is no clear message at all about the situation. The problem is that the USE flag is "hidden" on the package line as opposed to mentioned explicitly by portage. It's easy for software to print meaningful output based on the data it has while it is awkward for humans to scan lines and lines of output for parentheses with *s and -s. I very much appreciate that you clarified what you meant by "No". Thanks //Peter pgp6r0PcRQNo2.pgp Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner wrote: > There's a single problem. It can't enable abi_x86_32. Why didn't it > just say that? As per the full output, it does: !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. That together with ABI_X86="(64) (-32*) (-x32)" from the package line makes it clear that it is trying to change that USE flag. But as you haven't told emerge yet to do so, it doesn't; which makes it unable. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 11:24 AM, Tom Wijsman wrote: > On Thu, 14 Nov 2013 20:56:32 -0800 > Matt Turner wrote: > >> Attempting to merge =x11-proto/kbproto-1.0.6-r1 >> results in: >> >> x11-proto/kbproto:0 >> >> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) >> pulled in by (no parents that aren't satisfied by other packages in >> this slot) >> >> (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by >> >> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] >> required by (x11-libs/libX11-1.6.2::gentoo, installed) >> >> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] >> required by (x11-libs/libXt-1.1.4::gentoo, installed) > > No, it doesn't, it gives you a lot more output than that; you appear to > be distracted by something that doesn't appear to be a problem at all. What? Where do you get off telling me that the output I copied and pasted into this email is wrong? dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg =x11-proto/kbproto-1.0.6-r1 dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] x11-proto/kbproto-1.0.6-r1 ABI_X86="32 (64) (-x32)" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB dynamic71 mattst88 # sed -i -e 's|=x11-proto/kbproto|#=x11-proto/kbproto|' /etc/portage/package.keywords/xorg dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg #=x11-proto/kbproto-1.0.6-r1 dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] x11-proto/kbproto-1.0.6-r1 ABI_X86="(64) (-32*) (-x32)" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 02:24 PM, Tom Wijsman wrote: > On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner > wrote: > >> Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: >> >> x11-proto/kbproto:0 >> >> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) >> pulled in by (no parents that aren't satisfied by other packages >> in this slot) >> >> (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by >> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] >> >> required by (x11-libs/libX11-1.6.2::gentoo, installed) >> x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] >> >> required by (x11-libs/libXt-1.1.4::gentoo, installed) > > No, it doesn't, it gives you a lot more output than that; you > appear to be distracted by something that doesn't appear to be a > problem at all. > Not only that, but these spurious slot collision "errors" pop up all the time and are useful only for confusing portage users, unless they actually get it right in the very rare cases -- and they only get it right, it seems, when you don't see "no parents that aren't satisfied by other packages in this slot" on one side of the collision. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGdogACgkQ2ugaI38ACPBlWAD8CxzN2Q2jnkCZkmrXcBpTQNoD v30A1BnDvJen3JilQf0A/jm3aT/2B7vY7xwqTCnlaRE8VQNjgJQptn3HT7LRCic0 =nEcM -END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner wrote: > Attempting to merge =x11-proto/kbproto-1.0.6-r1 > results in: > > x11-proto/kbproto:0 > > (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) > pulled in by (no parents that aren't satisfied by other packages in > this slot) > > (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by > > x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] > required by (x11-libs/libX11-1.6.2::gentoo, installed) > > x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] > required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner wrote: > Attempting to merge =x11-proto/kbproto-1.0.6-r1 > results in: > > x11-proto/kbproto:0 > > (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) > pulled in by (no parents that aren't satisfied by other packages in > this slot) > > (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by > > x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] > required by (x11-libs/libX11-1.6.2::gentoo, installed) > > x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] > required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 10:54 AM, Peter Stuge wrote: > Matt Turner wrote: >> I think in large part recently it's because of use.stable.mask >> and package.use.stable.mask. These really are a nightmare for >> users. > .. >> I think most of the confusion is caused by the necessity to put >> a *stable* package atom into package.keywords to unmask a *USE* >> flag. > > A lot can be learned just from the filenames: > > use.stable.mask package.use.stable.mask > > The latter indicates that this concept has no less than four > dimensions. > > Let's enumerate and associate: > > 1. use - USE flags - no problem, Gentoo users either love USE flags > or leave 2. stable - arch vs. ~arch - no problem, even installation > docs describe it 3. mask - masked packages - OK, at some point > people encounter masked packages 4. package - per-package stuff - > like with /etc/portage/package.use > > How stable and mask interact with USE is absolutely unclear and > usability of this is very close to zero. Well, reordering this a bit: 1 - package: so this is per-package. 2 - use: so this has to do with use flags, per package 3 - stable: so this has to do with stable systems' use flags, per package 4 - mask: so this is disallowing something on stable systems' use flags, per package. So I don't think this is entirely unclear. I suppose it might be a bit more clear if it was called 'package.stable.use.mask', or the ideal english version of 'stable.package.use.mask', but i think renaming it at this point doesn't really provide that much of an advantage and definitely doesn't change what it does. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGRkUACgkQ2ugaI38ACPAu+gD/U6rExYFTC7fUMFIuQgbgJwRn I0sA9NSixk6gtVj8E8IA/i1jzlQnkjHQFnHw3qHnTtdUGpJHFn/0saxItbn6ieE9 =+7UA -END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Matt Turner wrote: > I think in large part recently it's because of use.stable.mask and > package.use.stable.mask. These really are a nightmare for users. .. > I think most of the confusion is caused by the necessity to put a > *stable* package atom into package.keywords to unmask a *USE* flag. A lot can be learned just from the filenames: use.stable.mask package.use.stable.mask The latter indicates that this concept has no less than four dimensions. Let's enumerate and associate: 1. use - USE flags - no problem, Gentoo users either love USE flags or leave 2. stable - arch vs. ~arch - no problem, even installation docs describe it 3. mask - masked packages - OK, at some point people encounter masked packages 4. package - per-package stuff - like with /etc/portage/package.use How stable and mask interact with USE is absolutely unclear and usability of this is very close to zero. //Peter
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 02:13 AM, Ulrich Mueller wrote: >> On Fri, 15 Nov 2013, Ben de Groot wrote: > >> As I see it now, with respect to multilib, we have three >> competing solutions, but not a clear direction which way we want >> to go as a distro: > >> 1: emul-* packages 2: multilib-portage 3: multilib.eclass > >> I would like to vote for option 1, as it is the least intrusive >> and does what we need. If it is really felt we need a more >> complete solution, then my vote would be for 2, since 3 is too >> intrusive and more likely to break or complicate stuff for normal >> users. > > Option 1 is not a solution, but a workaround. It has served us, but > IMHO its replacement is overdue. Just to give an example, stable > emul-linux-x86-xlibs suffers from several security issues (bug > 471098, A1/critical severity) since half a year. > > Besides, distributing pre-compiled binary packages seems very > un-Gentoo-ish. > > Not sure why you think that option 3 is more intrusive than option > 2. What can be more intrusive than requiring a modified package > manager? I concurr -- option #1 has existed for some time but it's entirely a workaround rather than a solution. Option 2 and Option 3, though, I don't see as having to be a competing system -- to me they provide for different goals (most of which overlap, but still). Multilib-portage provides the ability to build an entire userland in as many ABIs as can be supported -- bins, libs, the whole deal; no matter if the in-tree ebuilds have an alt-ABI specification or not. The multilib eclasses allow any ebuild that needs to, to depend on a non-native-ABI library and forces any package manager to work it out via use flags. #3 works for everyone in a more limited scope than #2 (just libs, generally with the goal of only including the few libs the in-tree consumers actually need). #2 provides users that want it with a specific PM to manage their system, as alternative to the other PMs out there. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGLzgACgkQ2ugaI38ACPCrkgD+JNG1iF/oGh/5gXtqhTXlhHGL A4tM6dbfZxmt793CTGwA+wercYN3gwb10GHyxs0bUMkime+cWDFpPphjPHU9BAtn =BPc1 -END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot wrote: > > I don't really want to bring up this episode again, but it is a > telling example, which you asked for. I appreciate that. I did ask for an example. I'll also limit my comments just to things that I think are more helpful moving forward. > > As can be seen from the ChangeLog, I was the primary maintainer. Depends on your definition of maintainer. If you define maintainer as somebody who has actually been doing work on a package, then you were. If you define it as the person listed in metadata.xml, then you weren't. Ideally those should match, so that when projects have to go running around the tree making changes they don't have to read between the lines to figure out who is the right contact for any particular package. They match now, which is good. > > I am even tempted to undo the multilib changes to freetype, since it > is still causing trouble (just search for freetype bugs and see how > often multilib pops up). Well, make sure you talk to the OTHER maintainer for that package, which is the multilib team, before doing that. You don't own the package - you just help to maintain it. I don't want to rehash the thread from last summer - I do appreciate your feelings and I'm trying to find a balance. I want to appreciate the fact that maintainers have the largest investment in their packages, but at the same time those working on projects are investing in Gentoo as well. >> >> Michał did add the multilib project as a co-maintainer, taking >> responsibility for dealing with the multilib-related issues long-term. >> In my mind this is the sort of things projects should do. > > Indeed, but more communication with the current actual maintainers of > the package in question should also be part of that. You're both "actual" maintainers now. Certainly I agree that you should be talking to each other. :) I'd hope that things are going better now, but if they aren't I'd hope that Comrel would provide some assistance here. > > I am also cautiously optimistic about a renewed QA team, which could > be involved more in this kind of issues. I tend to agree here, but their role isn't to pick winners so much as to defend the general integrity of the tree. I think the challenge is figuring out how good, "good enough," is before these packages end up in ~arch (which IS intended for TESTING packages, but packages that are fairly likely to work with some maintainer testing already). > If you say council should take more of a leadership role, then maybe > this issue can be decided by council and a clear direction be taken by > the distro as a whole? Then those who oppose the choice made can > either put up or shut up, and we can all work at implementing the > chosen solution. Should we pick an init system while we're at it? :) Honestly, I don't think we can really choose anything at this point as none of the solutions are really fully-baked. If the Council simply pronounced support for one of them the only result would be that people might stop working on the other two, with no further progress on the chosen one. Then if that one dies on the vine we're stuck. I do have thoughts around things that could be improved, but I don't think either of the new options are at the point where they make sense. Both options really have to progress further on their own before we can think about standardizing/etc. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 03:13 PM, Ulrich Mueller wrote: >> On Fri, 15 Nov 2013, Ben de Groot wrote: > >> As I see it now, with respect to multilib, we have three competing >> solutions, but not a clear direction which way we want to go as a >> distro: > >> 1: emul-* packages >> 2: multilib-portage >> 3: multilib.eclass > >> I would like to vote for option 1, as it is the least intrusive and >> does what we need. If it is really felt we need a more complete >> solution, then my vote would be for 2, since 3 is too intrusive and >> more likely to break or complicate stuff for normal users. > > Option 1 is not a solution, but a workaround. It has served us, > but IMHO its replacement is overdue. Just to give an example, > stable emul-linux-x86-xlibs suffers from several security issues > (bug 471098, A1/critical severity) since half a year. That's not an argument for or against anything, that just shows that we don't even have enough devs caring for the "easiest" method. Maybe ... dunno ... maybe that should be more automated so that a single trigger could generate the packages. > > Besides, distributing pre-compiled binary packages seems very > un-Gentoo-ish. Indeed. > Not sure why you think that option 3 is more intrusive than option 2. > What can be more intrusive than requiring a modified package manager? What's intrusive? We tolerate EAPI5, @preserved-rebuild and other package manager mods too ...
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
> On Fri, 15 Nov 2013, Ben de Groot wrote: > As I see it now, with respect to multilib, we have three competing > solutions, but not a clear direction which way we want to go as a > distro: > 1: emul-* packages > 2: multilib-portage > 3: multilib.eclass > I would like to vote for option 1, as it is the least intrusive and > does what we need. If it is really felt we need a more complete > solution, then my vote would be for 2, since 3 is too intrusive and > more likely to break or complicate stuff for normal users. Option 1 is not a solution, but a workaround. It has served us, but IMHO its replacement is overdue. Just to give an example, stable emul-linux-x86-xlibs suffers from several security issues (bug 471098, A1/critical severity) since half a year. Besides, distributing pre-compiled binary packages seems very un-Gentoo-ish. Not sure why you think that option 3 is more intrusive than option 2. What can be more intrusive than requiring a modified package manager? Ulrich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 15 November 2013 01:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote: >> I was particularly hit by this as maintainer of freetype, see bugs >> 455070 and 459352 for some of the mess that could have been avoided. > > Looks like 455070 was the source of problems there (the other is just > a tracker with the aftermath). The package had no maintainer at the > time, only a herd (per cvs). There was a request in the bug for > whether it was suitable to deploy to production. Somebody associated > with the herd gave a thumbs-up, apparently (I can only say that based > on your comment - I have no idea how that was communicated). Then > something went wrong. Since it caused problems, it was masked. Those > who run ~arch should be thanked for saving the stable users from > potential breakage! > > I'm not sure what should have been done differently. If the package > maintainer (in this case a herd) says that something is good to go, > why would anybody assume that it wasn't? You suggested testing in an > overlay 20 days earlier, but you weren't in any particularly > privileged position at the time (you were presumably just another > maintainer of the herd). I don't really want to bring up this episode again, but it is a telling example, which you asked for. As can be seen from the ChangeLog, I was the primary maintainer. As a member of the herd I didn't feel it necessary to assert any kind of "privilege" any other way. I had already said "no, or at least wait" but that was circumvented by asking another herd member who hadn't touched the package in years. It would have been nice were I asked for my okay before making any changes. And as can be seen, the mess I feared for indeed took place. This could have been prevented, in my opinion, had this seen more extensive testing in an overlay. And this is exactly why I am now more weary for the next package about to be mangled: cairo (bug 488672). I am even tempted to undo the multilib changes to freetype, since it is still causing trouble (just search for freetype bugs and see how often multilib pops up). > I'm not pointing fingers here. This was apparently a > miscommunication, and part of the cause was a failure to document that > there was a primary maintainer of the package (something which was > subsequently corrected). Michał did offer to just maintain the status > quo on that package instead of migrating it, and apparently he thought > he had the all-clear to migrate it anyway. > > Michał did add the multilib project as a co-maintainer, taking > responsibility for dealing with the multilib-related issues long-term. > In my mind this is the sort of things projects should do. Indeed, but more communication with the current actual maintainers of the package in question should also be part of that. > I'm sure there were other issues, but issues will happen when projects > make changes. That's just the way things roll around here. If Michał > just committed a change to a package without conferring with the > maintainer at all or giving significant notice, I'd feel differently. > I think we just need to learn and move forward, and from the looks of > things we have. Gentoo always has been a fairly "disruptive" distro, > though it has settled down of late. I don't think we're erring on the > side of breaking systems too often right now, though I'm always for > preventing that as long as it doesn't require ossification. > > (Just a note - this is all based on what I could piece together from > cvs and bugzilla. I'm sure those who were personally involved could > contribute more detail. I'm not sure it is necessary that do so, but > I'll gladly defer to those with firsthand knowledge.) > >>> In the end, stuff only >>> gets done if people write code. Your power in any FOSS project really >>> comes down to your ability to write code or convince others to write >>> code on your behalf. > >> No, it's more about your ability to commit and get away with it. > > So, I'm 100% for what Donnie said and in general I tend to lean > towards saying "thanks, but no thanks" when a heavy contributor is > driving everybody nuts. However, the reality is that those who commit > more also tend to be allowed to get away with committing more. That's > just human nature - we all like our free toys and we're reluctant to > take too much objection when we're slapped around a little by the guy > who is giving us the free toys. There needs to be a balance, and from > the sound of things Markos is looking to step in and adjust the > balance if it gets out of line. Honestly, I just wish everybody would > do what they can to make his job easier, and I say that without > pointing my fingers in any direction. I think we have a really great > thing going here... > > Rich > Markos has shown initiative and good ideas, so I'm looking forward to positive changes. I am also cautiously optimistic about a renewed QA team, which could be involved more
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 15 November 2013 17:56, Matt Turner wrote: > After using it for a month, he's now convinced that > Gentoo is clearly the most difficult to use. > > I'm inclined to agree, I'd have to disagree there slightly, arch is more easy to use if you stick to the core set, the binary packages ... as is debian. But if you verge outside that set, arch quickly becomes a headache, AUR may have lots of contribution, but its nowhere near the quality we have of even some of our worse quality overlays, and the arch toolchain lacks lots of features ebuild authors have come to rely on. This means if you use arch's equivalent of our overlays, you'll spend much time fixing up broken syntax in AUR packages. I mean, sure, its "simpler", but at the same time, it does so by simply cauterizing out the extra complexity, making it impossible for end users to even opt for the complex or different behaviours, by choosing one for them, and not informing them at all of that choice. So that argument mostly boils down to "useflags add complexity for people who aren't used to them, or aren't interested in them". -- Kent
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, Nov 13, 2013 at 2:28 AM, Martin Vaeth wrote: > The new "features" use.stable.mask and package.use.stable.mask > have turned maintaining systems with mixed ARCH and ~ARCH keywords > into a nightmare: I agree. I have helped two friends convert to Gentoo recently (one used it a few years ago). They both came from Arch, and one told me that before he resumed using Gentoo recently he considered these two distros in the same category in terms of difficulty of use and maintenance. After using it for a month, he's now convinced that Gentoo is clearly the most difficult to use. I'm inclined to agree, and I think in large part recently it's because of use.stable.mask and package.use.stable.mask. These really are a nightmare for users. Heck, they're really a nightmare for me and I've been using Gentoo for nine years and feel like I have a pretty good ability to decipher portage's error messages. I think most of the confusion is caused by the necessity to put a *stable* package atom into package.keywords to unmask a *USE* flag. (Am I doing something wrong that would prevent 'x11-proto/kbproto -abi_x86_32' in /etc/portage/package.use.stable.mask from un-stable-masking the abi_x86_32 USE flag for kbproto?) And then in addition, we did really weird things like stabilizing package versions whose only difference from the previous is that it supports multilib (e.g., kbproto-1.0.6 vs kbproto-1.0.6-r1). Except that it's package.use.stable.mask'd. So you have to keyword a stable package to get its only defining feature. (Why did we stabilize it in the first place?) Portage correctly shows that unstable USE flags are masked by printing parenthesis around them, like use.mask'd flags, but the error messages are really unhelpful. Take for instance dropping the stable =x11-proto/kbproto-1.0.6-r1 from package.keywords, in order implicitly mask the abi_x86_32. Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) There's a single problem. It can't enable abi_x86_32. Why didn't it just say that? You could even go beyond this and explain why it can't do it, but at this point I'd settle for a concise explanation of *what* it can't do.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 03:35 AM, Ciaran McCreesh wrote: > On Thu, 14 Nov 2013 20:07:39 +0100 > Thomas Sachau wrote: >> - multilib-portage was planned to add features with a future EAPI >> version, so in the end needs agreement from maintainers of package >> managers, the pms team and the council. If anyone from those groups >> only claims "you wrote so much, but i dont understand it, write >> more", then it can be a very long time to get it into the main tree >> (also this usually means it is well reviewed and tested) > > That's only a problem if you've got a horribly complicated feature > where you can't remember yourself what you changed to make it work or > how or why you implemented it. > ... or if people shift the goalpost so much that you don't even remember what game is being played
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 01:51 AM, Michał Górny wrote: >>> So tell me, what you exactly want or need? Or is it just bare >>> complaining for the sake of complaining? >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > 'Proper' is the keyword. The solution you mention has many issues that > I listed more than once, and is far from unobtrusive, clear > or explicit. It's supposedly working, yes, but it is nowhere near > production-ready. But at least the maintainer followed the protocol and did ask for feedback, did not just hammer it into the main tree etc. (Said maintainer was told to properly document AND DICSUSS it, or else ... one wonders why there's so much divergence between these two attempts)
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:07:39 +0100 Thomas Sachau wrote: > - multilib-portage was planned to add features with a future EAPI > version, so in the end needs agreement from maintainers of package > managers, the pms team and the council. If anyone from those groups > only claims "you wrote so much, but i dont understand it, write > more", then it can be a very long time to get it into the main tree > (also this usually means it is well reviewed and tested) That's only a problem if you've got a horribly complicated feature where you can't remember yourself what you changed to make it work or how or why you implemented it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Rich Freeman schrieb: > On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: >> >> So just "fix it as problems appear and/or we have some spare time" ... > > Have any problems appeared that impact anybody who hasn't tried to > take advantage of the new multilib features (ie modified their config > files/etc)? > >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > We get it - there are two competing approaches to multilib... That's > perfectly fine - we can sort out which one works better once they both > work. It would be more of a concern if maintainers were being asked > to maintain things twice, but as far as I'm aware the developers of > each of the competing approaches have been doing most of the work > themselves. > > Of course, there could be issues I simply haven't heard of. There is a pretty big issue/difference here: - multilib-portage was planned to add features with a future EAPI version, so in the end needs agreement from maintainers of package managers, the pms team and the council. If anyone from those groups only claims "you wrote so much, but i dont understand it, write more", then it can be a very long time to get it into the main tree (also this usually means it is well reviewed and tested) - the new multilib eclasses dont need any ok from anyone, so they have been added instantly after first creation of a draft. So after addition (also they only support a subset of the things supported by multilib-portage) ebuilds are now converted to use them for multilib support. Noone will opt to revert/convert those changes once multilib-portage would be ready, so the eclasses win simply by the lower entrance barrier In the end multilib-portage will likely end as a portage-only feature allowing multilib-support on packages without the need to change ebuilds (it also has support for wrapping binaries per ABI, but this will hopefully at some point also go into the eclasses). -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-14, o godz. 20:03:36 Patrick Lauer napisał(a): > On 11/14/2013 01:13 PM, Michał Górny wrote: > > https://wiki.gentoo.org/wiki/Multilib_porting_status > > > > That's the closest thing to a roadmap. > > So just "fix it as problems appear and/or we have some spare time" ... You could tell that. Or you could notice that this was specifically designed as an unobtrusive solution with possibility of gradual migration and backwards compatibility. > > So tell me, what you exactly want or need? Or is it just bare > > complaining for the sake of complaining? > > Well, you accidentally cut out all references to TommyD's work again. > Almost as if you don't even want to discuss a working proper solution > that just doesn't have the ego hammering it in ... 'Proper' is the keyword. The solution you mention has many issues that I listed more than once, and is far from unobtrusive, clear or explicit. It's supposedly working, yes, but it is nowhere near production-ready. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote: > I was particularly hit by this as maintainer of freetype, see bugs > 455070 and 459352 for some of the mess that could have been avoided. Looks like 455070 was the source of problems there (the other is just a tracker with the aftermath). The package had no maintainer at the time, only a herd (per cvs). There was a request in the bug for whether it was suitable to deploy to production. Somebody associated with the herd gave a thumbs-up, apparently (I can only say that based on your comment - I have no idea how that was communicated). Then something went wrong. Since it caused problems, it was masked. Those who run ~arch should be thanked for saving the stable users from potential breakage! I'm not sure what should have been done differently. If the package maintainer (in this case a herd) says that something is good to go, why would anybody assume that it wasn't? You suggested testing in an overlay 20 days earlier, but you weren't in any particularly privileged position at the time (you were presumably just another maintainer of the herd). I'm not pointing fingers here. This was apparently a miscommunication, and part of the cause was a failure to document that there was a primary maintainer of the package (something which was subsequently corrected). Michał did offer to just maintain the status quo on that package instead of migrating it, and apparently he thought he had the all-clear to migrate it anyway. Michał did add the multilib project as a co-maintainer, taking responsibility for dealing with the multilib-related issues long-term. In my mind this is the sort of things projects should do. I'm sure there were other issues, but issues will happen when projects make changes. That's just the way things roll around here. If Michał just committed a change to a package without conferring with the maintainer at all or giving significant notice, I'd feel differently. I think we just need to learn and move forward, and from the looks of things we have. Gentoo always has been a fairly "disruptive" distro, though it has settled down of late. I don't think we're erring on the side of breaking systems too often right now, though I'm always for preventing that as long as it doesn't require ossification. (Just a note - this is all based on what I could piece together from cvs and bugzilla. I'm sure those who were personally involved could contribute more detail. I'm not sure it is necessary that do so, but I'll gladly defer to those with firsthand knowledge.) >> In the end, stuff only >> gets done if people write code. Your power in any FOSS project really >> comes down to your ability to write code or convince others to write >> code on your behalf. > No, it's more about your ability to commit and get away with it. So, I'm 100% for what Donnie said and in general I tend to lean towards saying "thanks, but no thanks" when a heavy contributor is driving everybody nuts. However, the reality is that those who commit more also tend to be allowed to get away with committing more. That's just human nature - we all like our free toys and we're reluctant to take too much objection when we're slapped around a little by the guy who is giving us the free toys. There needs to be a balance, and from the sound of things Markos is looking to step in and adjust the balance if it gets out of line. Honestly, I just wish everybody would do what they can to make his job easier, and I say that without pointing my fingers in any direction. I think we have a really great thing going here... Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 23:12, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote: >>> I said >> As it is always happy to point out, Council doesn't see itself as >> leadership, just as a supreme court of appeal, when everything else >> seems to have failed. It likes to get involved as little as possible. > > The last time I talked to Council she said that she doesn't like it > when you anthropomorphize her. > > Certainly I stated in my manifesto that I believe that Council members > SHOULD be leaders, and should not limit their leadership of the distro > to casting votes. That's why we're chatting on a list, and I'm not > sitting back waiting for you to put this issue on a Council agenda. That is nice of you, but many of your fellow councilmen (historically, as well as currently) do not hold similar views, as was made painfully clear to me a few years ago. >>> We >>> also have Comrel, which is a better starting point for cases >>> concerning individuals vs policies. >> >> This also displays little real leadership. It concerns itself with >> conflict resolution, with various degrees of success. (I still have a >> bad taste in my mouth from my past dealings with that institution.) > > Well, that is the role of Comrel. I don't expect it to decide whether > developers can touch each other's ebuilds to add systemd units to > them, etc. However, if the Council establishes a policy then Comrel > should certainly take issue with devs that ignore that policy. Comrel > certainly can show leadership when it comes to how it operates, > facilitating better relations in the community in general, etc. > >> >> The costs are higher than the benefits, in my opinion. Where are the >> use cases for this high-cost solution that is being pushed upon us? > > Where are the costs for this high-cost solution that you purport the > existence of? Just what about this solution is difficult to maintain? > I keep hearing that it is painful, but I haven't seen specific > examples of HOW it is painful. See how much effort is expended on this, and how many maintainers are being involved: https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib I was particularly hit by this as maintainer of freetype, see bugs 455070 and 459352 for some of the mess that could have been avoided. >>> The problem with having top-down leadership in a volunteer-based >>> organization is that it tends to drive away anybody who doesn't agree >>> with the leader. If a supreme leader said "mgorny has the right >>> solution to multilib - everybody is going to work to implement it" >>> that would probably cause more harm than good. Everybody wants a >>> supreme leader until the leader backs something they oppose. >> >> But what's the alternative? Having a few dozen self-appointed leaders >> doing whatever they want, and often taking things in opposing >> directions. It's not top-down leadership, but rule of the strongest. > > When you have officially-appointed leaders they usually tend to be the > same people who would otherwise be the self-appointed leaders. They > just have more power to kick everybody out who disagrees with them. > It is still the rule of the strongest. How did Linus become the > leader of Linux? He wrote it... At least there is one person in charge who sets a clear direction, and is accountable. > I used to get philosophical about things like this, but I think the > model Gentoo has is actually not a bad one. I guess we'll have to agree to disagree on this one then. > In the end, stuff only > gets done if people write code. Your power in any FOSS project really > comes down to your ability to write code or convince others to write > code on your behalf. No, it's more about your ability to commit and get away with it. > We can argue about what piece of software is > conceptually the best, but implemented software will almost always win > over the unimplemented competitor, unless the merits of the competitor > are such that people will flock behind it and actually implement it. > > Rich > -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote: >> I said > As it is always happy to point out, Council doesn't see itself as > leadership, just as a supreme court of appeal, when everything else > seems to have failed. It likes to get involved as little as possible. The last time I talked to Council she said that she doesn't like it when you anthropomorphize her. Certainly I stated in my manifesto that I believe that Council members SHOULD be leaders, and should not limit their leadership of the distro to casting votes. That's why we're chatting on a list, and I'm not sitting back waiting for you to put this issue on a Council agenda. > >> We >> also have Comrel, which is a better starting point for cases >> concerning individuals vs policies. > > This also displays little real leadership. It concerns itself with > conflict resolution, with various degrees of success. (I still have a > bad taste in my mouth from my past dealings with that institution.) Well, that is the role of Comrel. I don't expect it to decide whether developers can touch each other's ebuilds to add systemd units to them, etc. However, if the Council establishes a policy then Comrel should certainly take issue with devs that ignore that policy. Comrel certainly can show leadership when it comes to how it operates, facilitating better relations in the community in general, etc. > > The costs are higher than the benefits, in my opinion. Where are the > use cases for this high-cost solution that is being pushed upon us? Where are the costs for this high-cost solution that you purport the existence of? Just what about this solution is difficult to maintain? I keep hearing that it is painful, but I haven't seen specific examples of HOW it is painful. >> The problem with having top-down leadership in a volunteer-based >> organization is that it tends to drive away anybody who doesn't agree >> with the leader. If a supreme leader said "mgorny has the right >> solution to multilib - everybody is going to work to implement it" >> that would probably cause more harm than good. Everybody wants a >> supreme leader until the leader backs something they oppose. > > But what's the alternative? Having a few dozen self-appointed leaders > doing whatever they want, and often taking things in opposing > directions. It's not top-down leadership, but rule of the strongest. When you have officially-appointed leaders they usually tend to be the same people who would otherwise be the self-appointed leaders. They just have more power to kick everybody out who disagrees with them. It is still the rule of the strongest. How did Linus become the leader of Linux? He wrote it... I used to get philosophical about things like this, but I think the model Gentoo has is actually not a bad one. In the end, stuff only gets done if people write code. Your power in any FOSS project really comes down to your ability to write code or convince others to write code on your behalf. We can argue about what piece of software is conceptually the best, but implemented software will almost always win over the unimplemented competitor, unless the merits of the competitor are such that people will flock behind it and actually implement it. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 20:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: >> On 14 November 2013 13:13, Michał Górny wrote: >>> >>> And how is it possible to discuss anything properly in Gentoo? >> >> That's because we have no proper leadership. We're an anarchistic >> collection of people working at cross-purposes at the best of times. >> There is no direction, and very little accountability. > > This seems to be an arrangement that everybody likes except when > somebody else does something differently than they would prefer... Seems, maybe. I for one do not like it at all, and I do bring that up from time to time. Others agree with me to various degrees. The problem is that it's so damn hard to change anything structurally in Gentoo. > We have a Council, and any issue can always be escalated there. As it is always happy to point out, Council doesn't see itself as leadership, just as a supreme court of appeal, when everything else seems to have failed. It likes to get involved as little as possible. > We > also have Comrel, which is a better starting point for cases > concerning individuals vs policies. This also displays little real leadership. It concerns itself with conflict resolution, with various degrees of success. (I still have a bad taste in my mouth from my past dealings with that institution.) > However, so far I haven't really seen any real indications of what the > concern is here. 32-bit software on amd64 has always been a kludge, > and if anything the latest multilib eclass seems to be less of a > kludge. I vehemently disagree. The emul-* packages may be a hack, but they work and cover the use cases we need. The new multilib eclass approach is much more intrusive in many packages, introduces new levels of complexity in ebuilds, with resulting new bugs and new behaviour that confuses users, and adding maintenance costs. It does this for very little gain. The great majority of our users doesn't need this functionality. The costs are higher than the benefits, in my opinion. Where are the use cases for this high-cost solution that is being pushed upon us? > Apparently some argue that there is a better solution being > worked on, and that's great to hear. What exactly is the problem? If > the eclass were breaking things that weren't already broken and having > a real impact on ordinary systems I'd consider that a concern. If you'd care to look at the history of bugs due to multilib eclass introduction in various packages, that's what you'd find. > The problem with having top-down leadership in a volunteer-based > organization is that it tends to drive away anybody who doesn't agree > with the leader. If a supreme leader said "mgorny has the right > solution to multilib - everybody is going to work to implement it" > that would probably cause more harm than good. Everybody wants a > supreme leader until the leader backs something they oppose. But what's the alternative? Having a few dozen self-appointed leaders doing whatever they want, and often taking things in opposing directions. It's not top-down leadership, but rule of the strongest. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer wrote: > > Apart from me masking a few things because portage couldn't figure out a > way to a consistent state, and all that ... That is vague. It may be true, but it does nothing to help anybody understand what is going on. I haven't had to mask anything, which suggests that we're doing things differently. That isn't to say that you're doing things wrong, but it is hard to take complaints seriously when they're vague. > > I mean, not that we had lots of users in #gentoo WTFing all over the > place, or something. Oh wait, we did. Honestly, I wish that a news item went out before it was implemented. I'll agree that there was some end-user impact - I suddenly saw portage outputting requests to set ABI on a few packages due to dependency issues. However, when I followed portage's instructions as with any USE dependency issue everything "just worked." > > I have no idea how you think we can sort out anything with a pre-set > conclusion. What pre-set conclusion? Nobody said that you can't work on multilib in portage. Nobody said you couldn't put it in the tree either, but I would avoid namespace collision/etc unless done in a way that is compatible with the eclass-based solution. When we get to the point where we have two options I'd be all for making it possible for users to pick which one they want to use. > Apart from the maintainers that now have to figure out the funny bugs of > the in-tree work ... unlike a certain overlay. But I keep repeating > myself, which is redundantly redundant. I'll be the first to admit that I haven't seen these bugs, so I won't say they aren't severe. However, at least a few examples of the sorts of things that could go wrong wouldn't hurt. Again, this is vague. > So instead of figuring out bugs the proper way ... we let users hit > them? I feel tempted to use the letters "A" and "Q" together. > > Also, I could again redundantly point at a certain overlay. > > Oh well. I guess I should complain less and package.mask more to express > my feelings... Complaining isn't the problem. The issue is that complaints aren't helpful if they lack any detail or suggestions that are likely to be acted upon. Nobody is going to move the new eclass into an overlay, and it is unlikely that anybody is going to spend a year tweaking packages in an overlay just to find that they're all obsolete when it comes time to merge them into the main tree. Besides, it isn't like an overlay would get much testing on this scale anyway. Overlays are great places to work out issues on a small scale with a few packages if you have multiple developers involved. They don't really accomplish much when you scale up, because your overlay is always going to be out-of-date compared to the main tree. Honestly, I'm not trying to pick sides here. I just see complaints about very new features, and my sense is that if those features aren't working they should simply not be used. I don't think I have that variable set to anything but 64 on my stable amd64 system and I haven't seen any problems with it recently. If there are problems I'm certainly interested in hearing about them. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: > On 14 November 2013 13:13, Michał Górny wrote: >> >> And how is it possible to discuss anything properly in Gentoo? > > That's because we have no proper leadership. We're an anarchistic > collection of people working at cross-purposes at the best of times. > There is no direction, and very little accountability. This seems to be an arrangement that everybody likes except when somebody else does something differently than they would prefer... We have a Council, and any issue can always be escalated there. We also have Comrel, which is a better starting point for cases concerning individuals vs policies. However, so far I haven't really seen any real indications of what the concern is here. 32-bit software on amd64 has always been a kludge, and if anything the latest multilib eclass seems to be less of a kludge. Apparently some argue that there is a better solution being worked on, and that's great to hear. What exactly is the problem? If the eclass were breaking things that weren't already broken and having a real impact on ordinary systems I'd consider that a concern. If it is just breaking things that never worked before then I'd just call it an experimental feature. The problem with having top-down leadership in a volunteer-based organization is that it tends to drive away anybody who doesn't agree with the leader. If a supreme leader said "mgorny has the right solution to multilib - everybody is going to work to implement it" that would probably cause more harm than good. Everybody wants a supreme leader until the leader backs something they oppose. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/14/2013 08:13 PM, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: >> >> So just "fix it as problems appear and/or we have some spare time" ... > > Have any problems appeared that impact anybody who hasn't tried to > take advantage of the new multilib features (ie modified their config > files/etc)? Apart from me masking a few things because portage couldn't figure out a way to a consistent state, and all that ... I mean, not that we had lots of users in #gentoo WTFing all over the place, or something. Oh wait, we did. >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > We get it - there are two competing approaches to multilib... That's > perfectly fine - we can sort out which one works better once they both > work. Given that one has been properly developed in an overlay, and one is now forcefully hammered into the main tree, it's a fait accompli. I have no idea how you think we can sort out anything with a pre-set conclusion. > It would be more of a concern if maintainers were being asked > to maintain things twice, but as far as I'm aware the developers of > each of the competing approaches have been doing most of the work > themselves. Apart from the maintainers that now have to figure out the funny bugs of the in-tree work ... unlike a certain overlay. But I keep repeating myself, which is redundantly redundant. > > Of course, there could be issues I simply haven't heard of. > >> There's this thing called overlay ;) >> Once you have everything prepared commit it all masked. >> A few days later if there's no obvious bug reports unmask it and duck. > > I'm not sure an overlay is a good solution for a tree-wide change that > will take months to roll out. It is great for testing the core > features with a small testing group, but the implementation is always > going to have to hit the whole tree and all its consumers with little > formal testing at that scale. So instead of figuring out bugs the proper way ... we let users hit them? I feel tempted to use the letters "A" and "Q" together. Also, I could again redundantly point at a certain overlay. Oh well. I guess I should complain less and package.mask more to express my feelings... Have a nice day, Patrick
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 13:13, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>> > It's also worth pointing out that the whole reason why abi_x86_32 is
>> > {package.,}use.stable.masked is because trying to manage the partial
>> > transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.
Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.
>> Well, discussing it properly would also maybe have been a good idea, but
>> since this is now getting unilaterally hammered in it's mostly about
>> damage limitation now ...
>
> And how is it possible to discuss anything properly in Gentoo?
That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: > > So just "fix it as problems appear and/or we have some spare time" ... Have any problems appeared that impact anybody who hasn't tried to take advantage of the new multilib features (ie modified their config files/etc)? > > Well, you accidentally cut out all references to TommyD's work again. > Almost as if you don't even want to discuss a working proper solution > that just doesn't have the ego hammering it in ... We get it - there are two competing approaches to multilib... That's perfectly fine - we can sort out which one works better once they both work. It would be more of a concern if maintainers were being asked to maintain things twice, but as far as I'm aware the developers of each of the competing approaches have been doing most of the work themselves. Of course, there could be issues I simply haven't heard of. > There's this thing called overlay ;) > Once you have everything prepared commit it all masked. > A few days later if there's no obvious bug reports unmask it and duck. I'm not sure an overlay is a good solution for a tree-wide change that will take months to roll out. It is great for testing the core features with a small testing group, but the implementation is always going to have to hit the whole tree and all its consumers with little formal testing at that scale. I guess my main question is what exactly is broken? I haven't heard of any large-scale problems with the new multilib rollout. I'm sure if I went looking for bugs I'd find them, but that's pretty much par-for-the-course for Gentoo. If I go install the latest gcc the day after it gets added to the tree and enable some new flag that was just introduced I'm going to find lots of packages that break. That doesn't mean that the new GCC wasn't ready for the tree - just that I went looking for trouble, found it, and now I have the opportunity to help out by filing bugs if what I actually did was reasonable. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/14/2013 01:13 PM, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>>> It's also worth pointing out that the whole reason why abi_x86_32 is
>>> {package.,}use.stable.masked is because trying to manage the partial
>>> transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.
So just "fix it as problems appear and/or we have some spare time" ...
> So tell me, what you exactly want or need? Or is it just bare
> complaining for the sake of complaining?
Well, you accidentally cut out all references to TommyD's work again.
Almost as if you don't even want to discuss a working proper solution
that just doesn't have the ego hammering it in ...
>> A more clean way would have been to target each of the emul-x86
>> libraries, replace one completely with multilib-enabled libraries, fix
>> all consumers, *then* unmask that whole shebang at once.
>
> We tried that. But in the end, it ended up masking new versions
> of a whole lot of libraries waiting for remaining maintainers'
> approval. And the maintainers that opposed the idea now complained that
> it caused the packages to be masked long...
There's this thing called overlay ;)
Once you have everything prepared commit it all masked.
A few days later if there's no obvious bug reports unmask it and duck.
> Feel free to convert all libraries, fix all consumers etc. We couldn't
> achieve that with our manpower.
So you just do it half-donkey'ed. Sigh.
Maybe ... you shouldn't do it if you can't properly finish it?
I mean, not like you cause a trail of destruction like the python-exec
fun, and such things ... maybe ... maybe ... you need to slow down and
plan more, and do your experiments in overlays.
Have fun,
Patrick
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-14, o godz. 07:49:55
Patrick Lauer napisał(a):
> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>
> > It's also worth pointing out that the whole reason why abi_x86_32 is
> > {package.,}use.stable.masked is because trying to manage the partial
> > transisition between emul-* and multilib-build dependencies
>
> ^^
>
> Why is there a partial random transition with no roadmap, no coordination?
https://wiki.gentoo.org/wiki/Multilib_porting_status
That's the closest thing to a roadmap.
So tell me, what you exactly want or need? Or is it just bare
complaining for the sake of complaining?
> A more clean way would have been to target each of the emul-x86
> libraries, replace one completely with multilib-enabled libraries, fix
> all consumers, *then* unmask that whole shebang at once.
We tried that. But in the end, it ended up masking new versions
of a whole lot of libraries waiting for remaining maintainers'
approval. And the maintainers that opposed the idea now complained that
it caused the packages to be masked long...
Feel free to convert all libraries, fix all consumers etc. We couldn't
achieve that with our manpower.
> Well, discussing it properly would also maybe have been a good idea, but
> since this is now getting unilaterally hammered in it's mostly about
> damage limitation now ...
And how is it possible to discuss anything properly in Gentoo?
On the mailing list where any serious thread is ignored, and silly
things and flamebaits are forked into three-four different, off-topic
threads like this one?
Don't tell me I didn't try to discuss it, that I didn't try to get
feedback. It's easy to complain almost one and a half year after
the original thread. Of course, AFAIR that thread went into the usual
'this seems like a shortened dup of what we were doing, you should
rather work for us'.
> > Note also that setting ABI_X86=32 globally isn't how it's supposed to
> > be used; the point of this flag is for dependency resolution when a
> > particular package requires it (ie, top-level package depends on
> > app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
> > changes to /etc/portage/package.use). But that's neither here nor there.
> >
> I find that quite silly ...
You *can* set it globally. But it's going to give you more 32-bit stuff
than you will ever use, so waste your time and space. We try to support
both the 'lazy' user and one wanting fine-grained control over packages.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies
^^
Why is there a partial random transition with no roadmap, no coordination?
In terms of planning and communication this is a horribly stupid thing
(also ignoring the existing working portage-mulitilib stuff that was
mostly pushed forward by TommyD and now is ignored in an overlay)
A more clean way would have been to target each of the emul-x86
libraries, replace one completely with multilib-enabled libraries, fix
all consumers, *then* unmask that whole shebang at once.
Well, discussing it properly would also maybe have been a good idea, but
since this is now getting unilaterally hammered in it's mostly about
damage limitation now ...
> Note also that setting ABI_X86=32 globally isn't how it's supposed to
> be used; the point of this flag is for dependency resolution when a
> particular package requires it (ie, top-level package depends on
> app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
> changes to /etc/portage/package.use). But that's neither here nor there.
>
I find that quite silly ...
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, Nov 13, 2013 at 10:02 AM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies on stable
> or mixed-keyworded systems is a horrible headache at the moment, due
> to those exact same unexplainable dependency errors. Without
> {package.,}use.stable.mask, all stable users would have to deal with
> this *right now* on their systems.
Indeed, by mixing keywords/etc Martin is basically having to deal with
this mess *right now.*
>
>
> Note also that setting ABI_X86=32 globally isn't how it's supposed to
> be used;
I never really viewed the new multilib stuff as being "ready for
primetime" anyway. That isn't meant to reflect on its level of
quality/etc - just that it isn't completely rolled out and the
docs/etc aren't really designed for end-user consumption yet.
Users who take advantage of new features in these kinds of states are
going to run into problems. That's just the cost of being on the
cutting edge.
Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/13 09:10 AM, Michał Górny wrote:
>>
>> 1. For several reasons I always want the most current
>> emul-linux-x86* libraries, so they are in
>> package.accept_keywords. Due to global ABI_X86=32 (which I also
>> want), this forced me of course to put several libraries to
>> ~amd64 since only new version support this. Some of the libraries
>> are actually stable, so I have removed them from
>> package.accept_keywords. So far, so good. But suddenly portage
>> spitted unexplainable dependency errors, and I only expert users
>> manually reading the profiles can understand that the reason is
>> that use.stable.mask requires that stable versions need to be
>> keyworded ~amd64 (or use.stable.mask has to be overridden in my
>> profile).
>
> Which wouldn't happen if package.accept_keywords didn't implicitly
> unmask flags.
>
(I haven't read this whole thread yet, but in case it hasn't been
mentioned:)
It's also worth pointing out that the whole reason why abi_x86_32 is
{package.,}use.stable.masked is because trying to manage the partial
transisition between emul-* and multilib-build dependencies on stable
or mixed-keyworded systems is a horrible headache at the moment, due
to those exact same unexplainable dependency errors. Without
{package.,}use.stable.mask, all stable users would have to deal with
this *right now* on their systems.
Note also that setting ABI_X86=32 globally isn't how it's supposed to
be used; the point of this flag is for dependency resolution when a
particular package requires it (ie, top-level package depends on
app-cat/dep[abi_x86_32], portage --autounmask-write sets the necessary
changes to /etc/portage/package.use). But that's neither here nor there.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlKDlI4ACgkQ2ugaI38ACPBopwD8CLqHS45H50Dg4Jnz5/JgpcKP
9BkjdulcBTGSIxyJX8sA/j2d+fojR0hCAJvsPsD24h90CWBvfhxnK824//aejoQi
=2vLL
-END PGP SIGNATURE-
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-13, o godz. 10:28:02 Martin Vaeth napisał(a): > As I understand, it tries to solve a "social" issue > (that an ARCH user might set a USE-flag which eventually > pulls in an ~ARCH package) on a technical level > (by forcibly disabling the USE-flag for the user). > Solving social problems by technical means is never a good > idea: Then you don't understand it. The basic issue is that we couldn't stabilize a package without stabilizing all of its optional dependencies. For example, consider Python 3.3. In order to get proper testing of it on testing, we had to enable support for it in packages. But when we introduced that support, the package immediately gained a dep on python:3.3. If the package was supposed to go stable, we would either have to stabilize Python 3.3 (too early for that), wait for Python 3.3 (resulting in very long to infinite) or drop Python 3.3 support. There were even cases when I had to revbump a package in order to keep 'limited' revision to stabilize and 'full' to keep testing. Just to be clear -- this isn't only a social issue. This is a valid QA concern that we had no distinction between 'flags that are fine on stable' and 'flags that are not'. If some flags work and some do not, resulting in 'unsatisfiable dep' errors, this is technical. > While the former gives the stable user a clear message > what is going wrong (after all, many stable users want > some package which has not a stable version yet, so this > should be something everybody should be able to handle), > the latter hides causes and makes things almost unpredictable: Answer yourself the following questions: does portage suggest removing the flag in the case? Does portage in any way explain that a particular dependency was pulled in due to USE flag? It's easy to use words like 'clear message' when you want to prove your point. And I have no idea what you mean by 'something everybody should be able to handle', unless you assume that the main purpose of a stable system is to turn it into mixed-keyword system. And just in case: the proper course of action then is to *report a bug*. And in the end, thanks to your glorified solution, we end up with dozens or hundreds of 'CANTFIX' bugs. > Even if the user has put the dependency into > package.accept_keywords, he will not be able to use the > USE-flag on his packages unless > *he puts stable versions into package.accept_keywords* > (or - simlarly worse - overrides the profile). If you have a problem with USE flag being masked, you unmask the USE flag. It is simple like this. I don't agree with the whole idea of unmasking flags via playing with accept_keywords. In my opinion, it's just a terrible bug or mis-design. It's not something that should be encouraged, or even happen. If you unmask testing package just to get testing keywords, you quickly lose the point of having stable keywords. Putting just the stable versions is a pointless nightmare. Even worse than that, people with mixed systems get extra flags even if they don't want them. And this is an easy way to have them end up with half of the system on testing. > The really bad thing is that this is happening by magic > "behind the user's back", i.e. contradicting the user's setting > of USE-flag and package.use: If the user does not carefully > read emerge's -v output, he even does not get informed that > the support for his unstable package is dropped from the > stable package, despite he might have specified the corresponding > USE-flag globally. Even worse, even when reading the output > carefully, the user cannot understand the reason: > Since there are many reasons why use-flags can appear in () > he will probably not even conjecture that actually something > will not be working as he expected. It's magic only because you did it wrong. > Here are some other examples of negative effects happening > just recently to me, ordered from not so severe to very bad: > > 1. For several reasons I always want the most current > emul-linux-x86* libraries, so they are in package.accept_keywords. > Due to global ABI_X86=32 (which I also want), this forced me > of course to put several libraries to ~amd64 since only > new version support this. Some of the libraries are actually > stable, so I have removed them from package.accept_keywords. > So far, so good. > But suddenly portage spitted unexplainable dependency errors, > and I only expert users manually reading the profiles can > understand that the reason is that use.stable.mask requires > that stable versions need to be keyworded ~amd64 > (or use.stable.mask has to be overridden in my profile). Which wouldn't happen if package.accept_keywords didn't implicitly unmask flags. > 2. Just a few days ago dev-lang/python-exec:2 became stable > on amd64, but dev-python/python-exec:2 is still ~amd64. And this was a bug that would have been fixed if you cared reporting it straight to us rather than kept is as an argument. > 3. As a side effect of 2., I rea
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, 13 Nov 2013 08:37:51 -0500 Rich Freeman wrote: > That said, your original email contained a few separate issues and > they're probably best dealt with individually. Just to set things straight: Note that these were different authors. > We're not going to have a common solution for multilib, stable use > masking, python-exec, and whatever other issues are lurking beneath > the surface. Not *yet*... :D -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, 13 Nov 2013 14:25:11 +0100
Thomas Kahle wrote:
> Hi,
>
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> > On Wed, 13 Nov 2013 10:28:02 + (UTC)
> > Martin Vaeth wrote:
> >
> >> Hello.
> >>
> >> The new "features" use.stable.mask and package.use.stable.mask
> >> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> >> into a nightmare:
> >
> > They are considered unsupported by many; so, going down that path
> > you need to be acquainted with Portage enough to keep a consistent
> > system.
>
> This argument has come up several times, but is it valid?
For more insight see
http://comments.gmane.org/gmane.linux.gentoo.devel/87839
and I quote "quite a few bugs are closed as invalid when a mixed system
is detected" as well as "mixing stable and testing is (likely) invalid
when unmasking one package in the unstable branch causes (reverse)
dependency resolution issues with another package in the stable branch".
Not to forget that we often test with everything stable or with
everything on testing; so, if you mix packages from both you end up in
untested situations where dependencies do not match what we intend.
Some of us fix them, but not everyone might; others might even just end
up setting a dependency range because of the stable / unstable mix.
Besides it being unsupported by some (I'll drop the "many" sound to it)
there are also just users in general that suggest others to avoid it;
simply because of the blockers and conflicts it brings along, it's
something that works out well for users that deeply understand what is
going on but for new users it is just a recipe for disaster.
Regardless of that, in my opinion, we should avoid encouraging
situations that result in having to deal with more unnecessary blockers
and conflicts; but that doesn't mean we don't want to see it. The same
link above highlights how it can help rather than obstruct Gentoo too.
> For me
> and other people I know, the main reason to use Gentoo is the
> rolling release model and this implies that you can mix package
> versions as long as version dependencies are satisfied. When the
> dependency is "cat/package" then this should mean that it works
> with every version. If it does not, then the ebuild's
> dependencies should be updated.
Given that maintainers often test against test versions and that arch
teams often test against stable versions, nobody really tests the rests
of the situations except for some people that mix and come across it;
so, effectively the version dependencies do not always match reality
and therefore cannot imply that you can mix it.
It's also very unrealistic to check every package for every bump; at
least not with the amount of work compared to the amount of manpower we
have, it does happen a lot and we are required to do so to some extent.
But you will note that this ends up in situations where the new version
just ends up being in package.mask for a long while, for example ffmpeg.
Others are either new and forgot or might show a lack of care; which
results in it being properly tested for non-mixed systems, but not
properly tested for mixed systems. Enumerating all dependency versions
is a quite busy job; we often rely on the restrictions listed
in ./configure.{in,ac} but those are not always correct either,
sometimes they are even just absent.
> The handbook says nothing about "unsupported":
>
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3
>
> If "many" choose to change this policy, there is no reason
> anymore for me to use Gentoo.
Which policy? It does not say anything about "supported" either. I
believe that its intention has always been to change it for some
packages, not for wide sets of them; the former doesn't cause much
problems, the latter is a recipe for disaster...
Note that it is merely unsupported by some developers, there are
definitely other developers that support it; and this does not imply
anything at all about our support venues.
> >> Similarly to the (fortunately dropped) concept of forcing
> >> useflags if certain packages are installed this forces a
> >> magic on the user which can hardly be managed since it is
> >> not clearly presented to the user but hidden in some profiles.
> >>
> >> As I understand, it tries to solve a "social" issue
> >> (that an ARCH user might set a USE-flag which eventually
> >> pulls in an ~ARCH package) on a technical level
> >> (by forcibly disabling the USE-flag for the user).
> >
> > That's one approach, it might also be used when a package can be
> > stabilized but a certain of feature of the package cannot; eg.
> > USE="minimal" could be broken on a certain package because it
> > removed a bit too much, thus it could be stabilized with
> > USE="-minimal" forced.
> >
> > Anyhow, I think we should make sure to weight "why we need to have
> > it" against "how it bothers which users"; and not just focus on
> > users alone.
> >
> > And other than that, are there alternatives? Something we
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote: > On 11/13/2013 12:39 PM, Tom Wijsman wrote: >> On Wed, 13 Nov 2013 10:28:02 + (UTC) >> Martin Vaeth wrote: >> >>> Hello. >>> >>> The new "features" use.stable.mask and package.use.stable.mask >>> have turned maintaining systems with mixed ARCH and ~ARCH keywords >>> into a nightmare: >> >> They are considered unsupported by many; so, going down that path you >> need to be acquainted with Portage enough to keep a consistent system. > > This argument has come up several times, but is it valid? Honestly, opinions vary on this one and I don't think it is a productive path to go down. I also feel that being able to mix keywords is a big benefit of using Gentoo. I'd rather focus on practical ways to make this easier rather than whether it is desirable. That said, there are always going to be situations where mixing keywords isn't practical. You're not going to run stable chromium against ~arch v8, or mixed keywords between kdelibs and kwin, etc. > We could consider reducing the feature set of portage and live > with the "problems" that arise. When I started using Gentoo a > package could simply not go stable until all dependencies for all > USE flags were also stable. Masking USE flags was reserved to a > short list of very special architecture depend special cases. I don't think going backwards is the solution. Back in the old days packages broke from time to time because we didn't have adequate ways to express dependencies, and I don't think it is a good solution to strip USE flags out of packages when they go stable so that users don't even have the option to use them. It makes more sense to identify what specifically is causing problems and come up with better solutions to them. That said, your original email contained a few separate issues and they're probably best dealt with individually. We're not going to have a common solution for multilib, stable use masking, python-exec, and whatever other issues are lurking beneath the surface. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Hi, On 11/13/2013 12:39 PM, Tom Wijsman wrote: > On Wed, 13 Nov 2013 10:28:02 + (UTC) > Martin Vaeth wrote: > >> Hello. >> >> The new "features" use.stable.mask and package.use.stable.mask >> have turned maintaining systems with mixed ARCH and ~ARCH keywords >> into a nightmare: > > They are considered unsupported by many; so, going down that path you > need to be acquainted with Portage enough to keep a consistent system. This argument has come up several times, but is it valid? For me and other people I know, the main reason to use Gentoo is the rolling release model and this implies that you can mix package versions as long as version dependencies are satisfied. When the dependency is "cat/package" then this should mean that it works with every version. If it does not, then the ebuild's dependencies should be updated. The handbook says nothing about "unsupported": http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3 If "many" choose to change this policy, there is no reason anymore for me to use Gentoo. >> Similarly to the (fortunately dropped) concept of forcing >> useflags if certain packages are installed this forces a >> magic on the user which can hardly be managed since it is >> not clearly presented to the user but hidden in some profiles. >> >> As I understand, it tries to solve a "social" issue >> (that an ARCH user might set a USE-flag which eventually >> pulls in an ~ARCH package) on a technical level >> (by forcibly disabling the USE-flag for the user). > > That's one approach, it might also be used when a package can be > stabilized but a certain of feature of the package cannot; eg. > USE="minimal" could be broken on a certain package because it removed a > bit too much, thus it could be stabilized with USE="-minimal" forced. > > Anyhow, I think we should make sure to weight "why we need to have it" > against "how it bothers which users"; and not just focus on users alone. > > And other than that, are there alternatives? Something we can do better? We could consider reducing the feature set of portage and live with the "problems" that arise. When I started using Gentoo a package could simply not go stable until all dependencies for all USE flags were also stable. Masking USE flags was reserved to a short list of very special architecture depend special cases. [...] >> 2. Just a few days ago dev-lang/python-exec:2 became stable >> on amd64, but dev-python/python-exec:2 is still ~amd64. >> Just to be sure to not miss anything, I have put the latter >> into package.accept_keywords, and hell break loose: > > Hell indeed breaks loose if you mix stable and unstable; but note that > this package had an accident, see the related news item for details. Do you mean stable and unstable in this case, or in general? [...] In general I share the sentiment. The complexity of using portage has increased a lot lately. Not only does it take long to find out why things suddenly go wrong after tree sync, also just the time until 'emerge -avUDN world' comes back with a proposal has grown to several minutes where it was few seconds when I started with Gentoo. There has been a lot of effort to make revdep-rebuild unessecary, but now that it is mostly implemented, I don't know if it was worth the price. I spend more time now just reconfiguring keywords to update the system than I spent back in the old days where revdep would just fix things. If the answer is, that I should not mix arch and ~arch, then I'll not use Gentoo anymore. Cheers, Thomas -- Thomas Kahle signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, 13 Nov 2013 10:28:02 + (UTC) Martin Vaeth wrote: > Hello. > > The new "features" use.stable.mask and package.use.stable.mask > have turned maintaining systems with mixed ARCH and ~ARCH keywords > into a nightmare: They are considered unsupported by many; so, going down that path you need to be acquainted with Portage enough to keep a consistent system. > Similarly to the (fortunately dropped) concept of forcing > useflags if certain packages are installed this forces a > magic on the user which can hardly be managed since it is > not clearly presented to the user but hidden in some profiles. > > As I understand, it tries to solve a "social" issue > (that an ARCH user might set a USE-flag which eventually > pulls in an ~ARCH package) on a technical level > (by forcibly disabling the USE-flag for the user). That's one approach, it might also be used when a package can be stabilized but a certain of feature of the package cannot; eg. USE="minimal" could be broken on a certain package because it removed a bit too much, thus it could be stabilized with USE="-minimal" forced. Anyhow, I think we should make sure to weight "why we need to have it" against "how it bothers which users"; and not just focus on users alone. And other than that, are there alternatives? Something we can do better? Sometimes problems can be resolved by better communication too; perhaps there are things we can inform the user about in pkg_postinst, or improve Portage to let the user know of a particular forced USE flag. > Solving social problems by technical means is never a good > idea: > > While the former gives the stable user a clear message > what is going wrong (after all, many stable users want > some package which has not a stable version yet, so this > should be something everybody should be able to handle), > the latter hides causes and makes things almost unpredictable: > > Even if the user has put the dependency into > package.accept_keywords, he will not be able to use the > USE-flag on his packages unless > *he puts stable versions into package.accept_keywords* > (or - simlarly worse - overrides the profile). That are indeed the two approaches, I don't see a problem with putting the version itself in accept_keywords or overriding the profile; furthermore, overriding forced and/or masked USE flag is the exception, it doesn't happen so frequently so I doubt this is a huge problem. > The really bad thing is that this is happening by magic > "behind the user's back", i.e. contradicting the user's setting > of USE-flag and package.use: If the user does not carefully > read emerge's -v output, he even does not get informed that > the support for his unstable package is dropped from the > stable package, despite he might have specified the corresponding > USE-flag globally. System upgrades have to be done carefully; so, the user skipping it is something we cannot account for except perhaps providing support for the user receiving some kind of verbose summary of such forces / masks being present at the end of the emerge output. But you'll have to contact the Portage developers to achieve such improvements. > Even worse, even when reading the output > carefully, the user cannot understand the reason: > Since there are many reasons why use-flags can appear in () > he will probably not even conjecture that actually something > will not be working as he expected. Most of these reasons can be uniquely determined from the output; but indeed, some might yield the same output, but this is again something that the Portage developers can improve and not a reason for removal. > Here are some other examples of negative effects happening > just recently to me, ordered from not so severe to very bad: > > 1. For several reasons I always want the most current > emul-linux-x86* libraries, so they are in package.accept_keywords. > Due to global ABI_X86=32 (which I also want), this forced me > of course to put several libraries to ~amd64 since only > new version support this. Some of the libraries are actually > stable, so I have removed them from package.accept_keywords. > So far, so good. > But suddenly portage spitted unexplainable dependency errors, > and I only expert users manually reading the profiles can > understand that the reason is that use.stable.mask requires > that stable versions need to be keyworded ~amd64 > (or use.stable.mask has to be overridden in my profile). This confuses me; isn't the goal to have one multilib apprach or the other? Especially due to the blockers between them. I agree Portage output can be better, I'm not sure if use.stable.mask is really the problem here though; but rather the nature of mixing them. > 2. Just a few days ago dev-lang/python-exec:2 became stable > on amd64, but dev-python/python-exec:2 is still ~amd64. > Just to be sure to not miss anything, I have put the latter > into package.accept_keywords, and hell break loose: Hell indeed breaks loose if you mix stable and
[gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Hello.
The new "features" use.stable.mask and package.use.stable.mask
have turned maintaining systems with mixed ARCH and ~ARCH keywords
into a nightmare:
Similarly to the (fortunately dropped) concept of forcing
useflags if certain packages are installed this forces a
magic on the user which can hardly be managed since it is
not clearly presented to the user but hidden in some profiles.
As I understand, it tries to solve a "social" issue
(that an ARCH user might set a USE-flag which eventually
pulls in an ~ARCH package) on a technical level
(by forcibly disabling the USE-flag for the user).
Solving social problems by technical means is never a good
idea:
While the former gives the stable user a clear message
what is going wrong (after all, many stable users want
some package which has not a stable version yet, so this
should be something everybody should be able to handle),
the latter hides causes and makes things almost unpredictable:
Even if the user has put the dependency into
package.accept_keywords, he will not be able to use the
USE-flag on his packages unless
*he puts stable versions into package.accept_keywords*
(or - simlarly worse - overrides the profile).
The really bad thing is that this is happening by magic
"behind the user's back", i.e. contradicting the user's setting
of USE-flag and package.use: If the user does not carefully
read emerge's -v output, he even does not get informed that
the support for his unstable package is dropped from the
stable package, despite he might have specified the corresponding
USE-flag globally. Even worse, even when reading the output
carefully, the user cannot understand the reason:
Since there are many reasons why use-flags can appear in ()
he will probably not even conjecture that actually something
will not be working as he expected.
Here are some other examples of negative effects happening
just recently to me, ordered from not so severe to very bad:
1. For several reasons I always want the most current
emul-linux-x86* libraries, so they are in package.accept_keywords.
Due to global ABI_X86=32 (which I also want), this forced me
of course to put several libraries to ~amd64 since only
new version support this. Some of the libraries are actually
stable, so I have removed them from package.accept_keywords.
So far, so good.
But suddenly portage spitted unexplainable dependency errors,
and I only expert users manually reading the profiles can
understand that the reason is that use.stable.mask requires
that stable versions need to be keyworded ~amd64
(or use.stable.mask has to be overridden in my profile).
2. Just a few days ago dev-lang/python-exec:2 became stable
on amd64, but dev-python/python-exec:2 is still ~amd64.
Just to be sure to not miss anything, I have put the latter
into package.accept_keywords, and hell break loose:
Portaqe wanted me to emerge the git version of
dev-lang/python-exec:0 and reemerge dozens of packages.
I needed hours to find out what is the actual cause:
The package.accept_keywords caused the use.stable.mask of
python_targets_pypy2_0 und python_targets_python3_3 to become
ineffective for dev-python/python-exec, but of course it is still
effective for dev-lang/python-exec which is not be the case
if I unmask the git version of dev-lang/python-exec.
This is completely confusing since nowhere the git-version
is marked differently than the non-git version.
So, yes, portage's behaviour can be explained, but, no,
it is not understandable by a user who wants portage
to report what is really wrong and who does not want
to check manually by reading all profiles and hunt down
for reasons why certain flags are magically forced/disabled.
3. As a side effect of 2., I realized that libreoffice and a dozen
further packages get forced a rebuild. So, if eventually
python-3.3 becomes stable and is removed from use.stable.mask,
all stable users will have to rebuild almost their whole world,
because python-exec then has one more "dummy" USE-flag. The same
will happen again if pypy-2.0 becomes stable.
So a lot of unnecessary rebuilds happen to stable users because
of {package.,}use.stable.mask which most of the developers
(who are often ~amd64 users) do not realize.
Best Regards
Martin
