Mike Frysinger posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 16 Sep 2005 18:17:01 -0400:
>> We still have KEYWORDS="-*". Sure, I know many do not like it, and if >> something was decided in regards to it, I missed it, but it is generally >> seen as 'less severe' than a package.mask'd mask, and its local to the >> package, so should not get stale. > > that would address the 'arch teams marking ahead of maintainer' issue, but in > general, i think we need a testing mask of some sort separate from > package.mask where we can put things like modular X, new KDE betas, new GNOME > betas, e17 packages, etc... Exactly. I'm a full ~arch user, and regularly load packages such as gcc4 (including snapshots once in awhile, plus the accompanying glibc and binutils) and kde and xorg snapshots, as well as pre versions of baselayout and portage, at times. I'd DEFINITELY be more convenient if I could easily separate the security and confirmed system munching stuff in package.mask out from these testing packages. ? arch would be great, here, as it would mean I could simply package.keyword as necessary, rather than (1) package.unmask, then sometimes (2) copying to overlay, and (3) adding ~arch and redigesting so portage will work with it. However, a testing.mask and parallel testing.unmask in /etc/portage, would work fine as well, provided when they were used, ~archs were carried over, to prevent having to overlay the package simply to add the appropriate keyword. (Being amd64 and having some packages do amd64 conditionals, I don't like adding ~x86 or -* to package.keywords, so overlay it has to be.) The point has been made that snapshots/pres/rcs and the like should never make it to ~arch, because they are never reasonable candidates for arch-stable. Point taken. However, that's certainly far easier for testers such as myself, than having to move a hundred kde-split-pkgs to overlay and keyword them, to be able to test the latest kde snapshot, then do the exact /same/ thing a week or two later for the /next/ one. For devs and users alike, an upstream package testing area (to parallel ~arch which is effectively ebuild testing and stable candidate area) that was separate and distinct from known actively harmful package.mask, would be /very/ useful, giving both advanced users and devs a way to know with no doubt what was considered ready for testing of the upstream-package, as deployed on Gentoo. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
