On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Yes, for all 3 people who have a clue what it means when virtual/x11 | gets pulled in. How many users do you seriously think will have a clue | and think "Oh, virtual/x11 is getting pulled in here. I must have a | package that isn't ported to modular X somewhere in this list. Let me | track it down and file a bug."?
When users suddenly see lots of extra X packages being pulled in that they don't need, it'll be rather obvious (and trivial to track down with --tree). Especially if it's documented somewhere that "packages that suddenly pull in lots of extra X packages usually means porting needed". | > * The clean solution is the solution originally proposed to this | > list, and the reason we are using new style virtuals. | | No, this is wrong. The reason we are using new style virtuals is so we | could have a versioning in what provides virtual/x11. Namely, 6.8 or | older. Uh, given that you can do that with old style virtuals, methinks that isn't the case... | > * There are currently enough unported packages that many ~arch users | > will probably have one or two installed (assumption: many users have | > several utterly random non-mainstream packages installed). | | Possible, but we can't prove this one way or the other. Certainly very | few modular X users have encountered apps that are still unported, as | evidenced by very few remaining blockers on #112675. Sure, but that's because there are relatively few users using hard masked packages. When you add it to ~arch the number will go up massively. | > * You are doing this because you believe that it is better to get | > every package ported over extremely quickly rather than having the | > odd package with extra unnecessary listed dependencies, and you do | > not consider the impact upon our users to be relevant. | | I consider ~arch users to have agreed to help test and fix new things. | This is included. I would not do the same thing to our stable tree, or | if we only had a stable tree. | | Yes, I do think it is better to have a quick solution and let some of | our ~arch users see a couple of blocks, for which they will file bugs. | Then these bugs will be fixed within a day, and those users will again | have working systems. ...or you could do things as originally planned, and have no non-working systems at all and the only consequences for end users will be a small number of extra packages (that they previously had installed anyway as part of hugeass X) being pulled in. | I don't see what the big deal is. By being ~arch users, they're | already asking to use ebuilds that have a chance of breaking their | systems permanently, let alone a single 'emerge sync'. They are asking to use ebuilds that may have undetected issues. They are not asking to use things that we know fine well are broken. ~arch is for "will hopefully go stable after further testing", not "stuff that has a very high chance of screwing you over". You're deliberately causing nasty problems for ~arch users when there's a very easy, clean workaround with far lower consequences and the same end result. This is unacceptable. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
