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 1FC2It-0004wk-8a for garchives@archives.gentoo.org; Wed, 22 Feb 2006 22:17:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1MMGjjl024341; Wed, 22 Feb 2006 22:16:45 GMT Received: from ender.volumehost.net (adsl-69-154-123-202.dsl.fyvlar.swbell.net [69.154.123.202]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1MMCcQc010680 for ; Wed, 22 Feb 2006 22:12:38 GMT Received: from localhost (localhost [127.0.0.1]) by ender.volumehost.net (Postfix) with ESMTP id ACCDCCD64 for ; Wed, 22 Feb 2006 22:12:37 +0000 (UTC) Received: from ender.volumehost.net ([127.0.0.1]) by localhost (ender.volumehost.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07216-12 for ; Wed, 22 Feb 2006 22:12:35 +0000 (UTC) Received: from monster (ip70-178-175-2.ks.ks.cox.net [70.178.175.2]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ender.volumehost.net (Postfix) with ESMTP id E7CB3CD4D for ; Wed, 22 Feb 2006 22:12:34 +0000 (UTC) From: "Boyd Stephen Smith Jr." To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] What happens with masked packages? Date: Wed, 22 Feb 2006 16:12:33 -0600 User-Agent: KMail/1.9.1 References: <200602222055.42113.tcoulon@decoulon.ch> <43FCC33D.7000303@joat.com> <200602222138.01006.tcoulon@decoulon.ch> In-Reply-To: <200602222138.01006.tcoulon@decoulon.ch> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200602221612.33988.bss03@volumehost.com> X-Virus-Scanned: amavisd-new at volumehost.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k1MMCcQc010680 X-Archives-Salt: cf66f033-045d-4138-8101-3f9b8f0b07c7 X-Archives-Hash: e1196b8709ca3873dd87483f30877bc8 On Wednesday 22 February 2006 14:38, Thierry de Coulon wrote about 'Re: [gentoo-user] What happens with masked packages?': > Thanks. Does not seem to me to be the best solution, though: if a > package is masked, many users won't install it, so what's the absence of > bug report indicating? I hate how emerge / portage calls a missing keyword "masked". It's really not the same thing as being in package.mask (so called "hard-masked"). In package.mask there is something decidedly broken, be it compatibility or otherwise. But, there's often nothing wrong with testing besides being new. ~ARCH is testing, ARCH is stable. It's like debian's stable/testing/unstable braches, but more fluid. On gentoo, packages are generally moved from testing to stable individually, with batch moves reserved for suites (like KDE or Gnome) or packages with migration issues. We have a number of users just on this mailing list that run testing systems all day long. We encounter more bugs than stable users, but that's alright because we /want/ to test things, and have no fear of submitting a bug. Now, if you want to fire off automated 'emerge -u world's every night, I'd suggest staying away from testing. So far, the system has mostly worked. I *would* like to see some changes, but mainly due to the fact that ~ARCH and package.mask are used for two purposes right now. See below. > In my case, the funny thing is: DVDRIP is not masked and does not work. > Acidrip is masked and works like a charm. Is the DVD:Rip ebuild doing something incorrectly, or is it just a poor package from upstream? In the former case, please file a bug at bugs.gentoo.org. In the latter, a bug can be filed, but it's more likely to get attention in upstream rather than at bugs.gentoo.org. I'm not sure /exactly/ what you want from your ripping program, but I'd check out ANDREW (ANDREW's Not a DVD Ripping and Encoding Wizard) from the FSF. Sooner or later I'm gonna write an ebuild for that sucka. (Only my rant and .sig follow, so no need to scroll if you don't want my opinion.) Right now, we see package.mask, -*, and sometimes even ~ARCH being used to indicate instability from upstream. For example, the gcc-4.1 ebuilds work perfectly, yet are marked -*. As another example, there was a bit of time when the KDE 3.5_beta2 ebuilds worked fine (and were ~ARCH) but they were package.mask'ed. >>From what I understand this is incorrect. package.mask, -*, and the ~ARCH (and occasionally, -ARCH) keywords are supposed to indicate the /ebuild/'s stability, not the upstream stability. The problem is, we can't simply drop the practice of package.mask or -*'ing things like gcc-4.1 or beta versions of a DE that a good number of gentoo users work with everyday. Too many systems would break if such ebuilds were marked STABLE with no indication that *you are installing software that might not work*. What's really needed is a separate field indicating upstream classification, something similar to ACCEPT_KEYWORDS but indicating not the stability / behavior of the ebuild, but of the package from upstream. This would help both users (they can choose the test ebuilds, upstream, or both) and developers (they don't have to ever think "Was upstream broken or was the ebuild?" when they see a *-). We could also do away with the perpetually masked cvs / -9999 versions. It would be something like ACCEPT_UPSTREAM="BETA" in make.conf where you might also have HEAD, SNAPSHOT, ALPHA, RELEASE_CANDIDATE, RELEASE, BUG_FIX, SECURITY_FIX instead of BETA; Also there would either be special logic for HEAD or an additional flag in the ebuild for "always upgrade, even to same version", but I suppose that's a different matter. Of course, this would require significant work, and may not even be something the gentoo developers would be interested in. (The existing system seems to work OK, even if it's not ideal.) But, that's my two cents, hopefully I won't feel the need to bore the entire mailing list with this again for a while. (Or maybe I'll get off my digital butt and learn enough about portage to fix it myself, or at least file a GLEP) -- Boyd Stephen Smith Jr. bss03@volumehost.com ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list