Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: first council meeting
Date: Sat, 24 Sep 2005 13:51:40
In Reply to: Re: [gentoo-dev] first council meeting by Mike Frysinger
1 Mike Frysinger posted <200509161817.01181.vapier@g.o>, excerpted
2 below, on Fri, 16 Sep 2005 18:17:01 -0400:
4 >> We still have KEYWORDS="-*". Sure, I know many do not like it, and if
5 >> something was decided in regards to it, I missed it, but it is generally
6 >> seen as 'less severe' than a package.mask'd mask, and its local to the
7 >> package, so should not get stale.
8 >
9 > that would address the 'arch teams marking ahead of maintainer' issue, but in
10 > general, i think we need a testing mask of some sort separate from
11 > package.mask where we can put things like modular X, new KDE betas, new GNOME
12 > betas, e17 packages, etc...
14 Exactly. I'm a full ~arch user, and regularly load packages such as gcc4
15 (including snapshots once in awhile, plus the accompanying glibc and
16 binutils) and kde and xorg snapshots, as well as pre versions of
17 baselayout and portage, at times.
19 I'd DEFINITELY be more convenient if I could easily separate the security
20 and confirmed system munching stuff in package.mask out from these testing
21 packages. ? arch would be great, here, as it would mean I could simply
22 package.keyword as necessary, rather than (1) package.unmask, then
23 sometimes (2) copying to overlay, and (3) adding ~arch and redigesting so
24 portage will work with it. However, a testing.mask and parallel
25 testing.unmask in /etc/portage, would work fine as well, provided when
26 they were used, ~archs were carried over, to prevent having to overlay the
27 package simply to add the appropriate keyword. (Being amd64 and having
28 some packages do amd64 conditionals, I don't like adding ~x86 or -* to
29 package.keywords, so overlay it has to be.)
31 The point has been made that snapshots/pres/rcs and the like should never
32 make it to ~arch, because they are never reasonable candidates for
33 arch-stable. Point taken. However, that's certainly far easier for
34 testers such as myself, than having to move a hundred kde-split-pkgs to
35 overlay and keyword them, to be able to test the latest kde snapshot, then
36 do the exact /same/ thing a week or two later for the /next/ one. For
37 devs and users alike, an upstream package testing area (to parallel ~arch
38 which is effectively ebuild testing and stable candidate area) that was
39 separate and distinct from known actively harmful package.mask, would be
40 /very/ useful, giving both advanced users and devs a way to know with no
41 doubt what was considered ready for testing of the upstream-package, as
42 deployed on Gentoo.
44 --
45 Duncan - List replies preferred. No HTML msgs.
46 "Every nonfree program has a lord, a master --
47 and if you use the program, he is your master." Richard Stallman in
51 --
52 gentoo-dev@g.o mailing list