1 |
2008/11/25 Duncan <1i5t5.duncan@×××.net>: |
2 |
> "Mark Knecht" <markknecht@×××××.com> posted |
3 |
> 5bdc1c8b0811241446s7b7b01e7qba78f4e6de060a38@××××××××××.com, excerpted |
4 |
> below, on Mon, 24 Nov 2008 14:46:35 -0800: |
5 |
> |
6 |
>>> Personally, I default to ~arch, and unmask hard-masked packages either |
7 |
>>> in- tree or from various overlays from time to time as well. |
8 |
>> |
9 |
>> Where do you do this? In /etc/make.conf? I've never run a machine like |
10 |
>> that but would be interested in at least seeing how many packages this |
11 |
>> machine would have to rebuild if I went there. |
12 |
> |
13 |
> Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable |
14 |
> amd64 as well, as shown by an emerge --info) in /etc/make.conf. You'd be |
15 |
> surprised at how far out of date stable arch is in some cases. Of course |
16 |
> in other cases, generally mature and real slow moving packages, the |
17 |
> latest version available has long been stable on most or all archs (see |
18 |
> below). |
19 |
> |
20 |
if i recall corectly in the past some packages that were under amd64 only needed |
21 |
also accept keywords amd64 near ~amd64. has this changed lately? usually the |
22 |
latest includes the former but sometimes when the packages are just amd64 and |
23 |
no ~amd64 ones i remember that i needed to add amd64 also in the keywords. |
24 |
|
25 |
>> Generally I've always run stable and then never shied away from having a |
26 |
>> larger set of file in my package.keywords file to get what I think I |
27 |
>> want to run. |
28 |
> |
29 |
> With ~arch by default, you normally have very few packages listed in |
30 |
> package.keywords. There /may/ be a few individual packages that you |
31 |
> choose to stay with stable on, but at least here, I don't use |
32 |
> package.keywords for that but rather, package.mask, and mask whatever |
33 |
> individual version I'm having problems with, thereby forcing portage back |
34 |
> to a previous version, whether that's stable or an earlier ~arch version. |
35 |
> |
36 |
i found out that is better to have a less long package.mask instead of |
37 |
a long package.unmask. |
38 |
it's faster to controll the stuff in your pc. |
39 |
|
40 |
>> I don't think that running 'stable' anymore really means stable. package |
41 |
>> management has (IMO, really) gotten rather arbitrary over the last 2 |
42 |
>> years to the extent that I know of multiple people who have left the |
43 |
>> distro because stable packages are really broken. It's hard on some |
44 |
>> people with certain workload models (say a professional recording |
45 |
>> studio) to run stable, do updates, find new software is broken, and then |
46 |
>> have to downgrade. Lost time is lost money. I know of at least 4 that |
47 |
>> have moved onto other prepacked distros in the last year. Disappointing. |
48 |
> |
49 |
> I've heard that before, but as I run ~arch by default, I obviously have |
50 |
> no personal experience to go on. What I believe happens is that devs by |
51 |
> definition will be running ~arch on many of their boxes, and that while |
52 |
> they are supposed to and I'm sure do actually test on a stable box before |
53 |
> marking stable, the test sample size is by practical reality relatively |
54 |
> small, and sometimes, when the package hits the larger stable user base, |
55 |
> there /will/ be the occasional configuration that breaks, because there |
56 |
> was simply no case of it in the tested sample base. |
57 |
> |
58 |
if there's the lack of testing devs for going into stable i don't |
59 |
really know if it worths |
60 |
to continue keeping this distinction. maybe it would be better to have something |
61 |
like a hardened branch in which to go with only stable and secure |
62 |
stuff that gets |
63 |
updated rarely but that can be used as production system. more like the fedora |
64 |
red hat enterprise approach, where red hat is very stable and not |
65 |
updated very often |
66 |
if not for security reasons and fedora that gets the new stuff. |
67 |
|
68 |
> At least Gentoo stable isn't /that/ bad! We got our updates and the GLSA |
69 |
> out, and the old/vulnerable versions hard/security masked and then |
70 |
> removed. But perhaps you get the idea why I don't find stable a choice |
71 |
> particularly usable for me personally at least, now. Of course I'm |
72 |
> closer to pan upstream than anything else, but knowing what I know about |
73 |
> stale stable packages often lacking all the fixes (security and |
74 |
> otherwise) of the latest upstream version with pan, it has only made me |
75 |
> more of a confirmed ~arch user than I would have been otherwise. |
76 |
> |
77 |
well, glsa sometimes aren't marked right. i still have some glsa that |
78 |
get out from time to time that |
79 |
have already been fixed. an example is unace. |
80 |
|
81 |
-- |
82 |
dott. ing. beso |