From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F1ebk-00038y-Gi for garchives@archives.gentoo.org; Wed, 25 Jan 2006 06:58:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0P6uvGl013502; Wed, 25 Jan 2006 06:56:57 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0P6raLY018303 for ; Wed, 25 Jan 2006 06:53:36 GMT Received: from [213.121.151.206] (helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1F1eXA-0004Fh-6d for gentoo-dev@lists.gentoo.org; Wed, 25 Jan 2006 06:53:36 +0000 Received: from localhost ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1F1eX5-00066K-Ei for gentoo-dev@lists.gentoo.org; Wed, 25 Jan 2006 06:53:31 +0000 Date: Wed, 25 Jan 2006 06:53:27 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Unmasking modular X Message-ID: <20060125065327.2d39a0d2@snowdrop.home> In-Reply-To: <43D71A79.6020104@gentoo.org> References: <43D5D1E4.9020801@gentoo.org> <20060124071808.14fcecc3@snowdrop.home> <43D5D84C.5000105@gentoo.org> <20060125012137.2c706947@snowdrop.home> <43D71A79.6020104@gentoo.org> X-Mailer: Sylpheed-Claws 2.0.0-rc3 (GTK+ 2.8.10; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_L=ZACD.ti8OA.5U/zu1JNef"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 635f55c3-eb18-4c46-8a83-6efb9812cee5 X-Archives-Hash: 8cf967c0cf69492b51d564c59781da77 --Sig_L=ZACD.ti8OA.5U/zu1JNef Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz 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. |=20 | 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). |=20 | 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. |=20 | 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. |=20 | 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. --=20 Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --Sig_L=ZACD.ti8OA.5U/zu1JNef Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD1yBq96zL6DUtXhERAn2SAJ9FSNEhBkszRzplljOFa3MIONcbCACZATTj x+TiPMFRJuVrA73K6KYU6T8= =WK7a -----END PGP SIGNATURE----- --Sig_L=ZACD.ti8OA.5U/zu1JNef-- -- gentoo-dev@gentoo.org mailing list