1 |
2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de>: |
2 |
> |
3 |
> On Mittwoch, 30. Januar 2008, Duncan wrote: |
4 |
> > Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de> posted |
5 |
> > 200801300220.21430.volker.armin.hemmann@××××××××××××.de, excerpted |
6 |
> below, |
7 |
> > |
8 |
> > on Wed, 30 Jan 2008 02:20:21 +0100: |
9 |
> > >> also adding --as-needed as LDFLAGS should help you save some time in |
10 |
> > >> recompiling stuff.... |
11 |
> > > |
12 |
> > > yeah - no. Don't do it. It breaks stuff. |
13 |
> > |
14 |
> > I think the breakage in most of the common stuff Gentoo devs anyway use |
15 |
> > has been fixed by now. I know I've had surprisingly few problems (read, |
16 |
> > ZERO problems) with it here. Surprising, as I expected at least a few, |
17 |
> > but I've seen exactly ZERO. |
18 |
> > |
19 |
> > That said, especially for those who just want things to work, without |
20 |
> > having to futz with LDFLAGS and remerge something occasionally, I'd |
21 |
> still |
22 |
> > not recommend it. For those that enjoy the challenge of such things, |
23 |
> > however, I'd say great! Go for it! And for those in the middle, well, |
24 |
> > YMMV, as the saying goes. You probably lean one way or the other, so |
25 |
> > take your pick. |
26 |
> |
27 |
> aren't bug reports with --as-needed closed as invalid per default? |
28 |
|
29 |
|
30 |
they might be, but the fact is that the flag is good and working well. |
31 |
|
32 |
> |
33 |
> > As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I |
34 |
> > started on Gentoo. |
35 |
> |
36 |
> when I started with gentoo, there was no 'stable' or 'unstable'. |
37 |
> |
38 |
> And IMHO that was a lot better. But some day some people tried to turn |
39 |
> gentoo |
40 |
> into a 'debian from source'. |
41 |
|
42 |
|
43 |
hmmm.... from what i remember gento always had stable/unstable branches. |
44 |
i've started using it about 4 or 5 years ago and for what i remember the 2 |
45 |
branches were there already.... |
46 |
|
47 |
> In fact, I've read suggestions that Gentoo tends to |
48 |
> > work better at ~arch than at stable, because ~ is where most developers |
49 |
> > are, and it's not uncommon for certain incompatibilities with "old" |
50 |
> > software, that is, the crufty stable stuff from months or years ago |
51 |
> > that's common in stable, to be overlooked until some poor stable keyword |
52 |
> > user files a bug. Yes, before stabilizing, the arch-devs and arch- |
53 |
> > testers normally test a package against a full-stable system, but it's |
54 |
> > simply not possible to test against every permutation of USE flags and |
55 |
> > mix of merged apps. While it's certainly true that ~arch packages have |
56 |
> > the same issue, at least there there's a decently active community of |
57 |
> > testers actively reporting bugs and devs fixing them. |
58 |
> |
59 |
> from my experience, go stable or unstable. But don't mix. And a better |
60 |
> name |
61 |
> for stable would be 'stale'. |
62 |
> |
63 |
> That said, a lot of problems who hit me as an unstable user hit my |
64 |
> 'stable' |
65 |
> friends too. So why use 'stable' at all? |
66 |
|
67 |
|
68 |
well, i had more problems with whole unstable system. the whole unstable |
69 |
could mix up your system, since a daily update, as i do, especially on |
70 |
system packages is bad. it could push in some bad stuff inside. |
71 |
|
72 |
> |
73 |
> > |
74 |
> > <brainstorming> What would be great would be a keyword system that would |
75 |
> > allow just this, say ~ for initial testing, automatically upgraded to / |
76 |
> > after the week UNLESS they've been marked ~~, with the extra ~ |
77 |
> > automatically added to ~ packages by a script if a bug has been filed, |
78 |
> > blocking the automatic upgrade to /, and a bugzilla keyword that a dev |
79 |
> > could add to put the package back on automated / track if they've |
80 |
> decided |
81 |
> > the bug isn't worth derailing the automated / upgrade over. Then people |
82 |
> > could go full testing ~ mode if they wanted, / mode if they wanted |
83 |
> almost |
84 |
> > ~ but wanted to be spared the pain of the most obvious bugs as found in |
85 |
> > the initial testing wave, and full stable arch if they wanted crufty old |
86 |
> > packages, say for a server only upgraded for security issues or the |
87 |
> like, |
88 |
> > somewhere. </brainstorming> |
89 |
> |
90 |
> what would be great would be recognizing that 'stable' does not work. |
91 |
|
92 |
|
93 |
the problem is that stable needs a lot of testing. and the devs don't have |
94 |
the time to test is anymore. kde3.5.8 went stable yesterday, but i've been |
95 |
using it from when it got into portage without problems. also, there are a |
96 |
lot of unstable packages that the people need so what i'd suggest is the |
97 |
removal of stable for non-system packages. |
98 |
|
99 |
> |
100 |
> > Of course, YMMV, but ~ for the entire system, with appropriate site |
101 |
> based |
102 |
> > masking as Gentoo already makes possible with /etc/portage/package.mask |
103 |
> > and the like, isn't as terrible or system breaking as some folks like to |
104 |
> > make it out to be. By policy, ~ is only for stable track packages in |
105 |
> the |
106 |
> > first place. Obviously broken packages and those not considered stable |
107 |
> > candidates normally never get even the ~ keyword, as they are kept in |
108 |
> > development overlays or in the tree but without keywords or fully hard |
109 |
> > masked, so ~ packages aren't the broken things a lot of people make them |
110 |
> > out to be. |
111 |
> |
112 |
> exactly. |
113 |
> |
114 |
> ~arch is not for broken packages, brocken or highly experimental stuff is |
115 |
> in |
116 |
> package.mask. |
117 |
|
118 |
|
119 |
or doesn't get into portage at all.... usually a package that is broken |
120 |
isn't in portage, unless it has already gotten into, but was found broken. |
121 |
|
122 |
-- |
123 |
> gentoo-amd64@l.g.o mailing list |
124 |
> |
125 |
> |
126 |
|
127 |
|
128 |
-- |
129 |
dott. ing. beso |