| 1 |
On Tue, May 03, 2016 at 09:46:10PM -0700, Matt Turner wrote |
| 2 |
> On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert <floppym@g.o> wrote: |
| 3 |
> > On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers <jer@g.o> wrote: |
| 4 |
> >> The solution is to have people with an actual interest in a specific |
| 5 |
> >> architecture determine whether stabilising a package is viable, and |
| 6 |
> >> taking sensible action, like dropping stable keywords where applicable. |
| 7 |
> > |
| 8 |
> > If these people do not actually exist or are not doing their job by |
| 9 |
> > culling the depgraph appropriately, we should really drop a number of |
| 10 |
> > archs from "stable" status. |
| 11 |
> |
| 12 |
> I mostly agree, modulo the comment about people "doing their jobs". |
| 13 |
> Arch testing completely sucks. |
| 14 |
> |
| 15 |
> Having built many stages for an "unstable" arch (mips) has taught me |
| 16 |
> one thing: it's awful being unstable-only. There's no end to the |
| 17 |
> compilation failures and other such headaches, none of which have |
| 18 |
> anything at all to do with the specific architecture. |
| 19 |
> |
| 20 |
> Short of adding a middle level ("stable, wink wink nudge nudge") where |
| 21 |
> things at least compile, I think the current situation is actually |
| 22 |
> significantly better than the alternative of dropping them to |
| 23 |
> unstable. |
| 24 |
|
| 25 |
Matt points out a problem with the current situation. There are |
| 26 |
basically 2 levels of unstable... |
| 27 |
|
| 28 |
1) Ancient or really new stuff that doesn't compile, let alone run, in |
| 29 |
the presence of current libraries. |
| 30 |
|
| 31 |
2) Stuff that actually works, but the devs have not stabilized it yet. |
| 32 |
|
| 33 |
People who accept unstable ~arch generally want the second group, but |
| 34 |
going all out ~arch brings in builds from the first group, which breaks |
| 35 |
systems. The way to get "the best of both worlds" is to start with |
| 36 |
stable, and only keyword stuff that you need, which is hopefully in the |
| 37 |
second group. That can get painfull with multiple dependancies, |
| 38 |
requiring re-iterative multiple runs and keywording. Can I make a |
| 39 |
suggestion here? Is it possible for the devs to come up with with... |
| 40 |
|
| 41 |
emerge --keyword-write |
| 42 |
|
| 43 |
... similar to "emerge --autounmask-write", but have it write to |
| 44 |
package.accept_keywords, rather than package.unmask? |
| 45 |
|
| 46 |
That would achieve the effect that people are looking for, with less |
| 47 |
work. |
| 48 |
|
| 49 |
-- |
| 50 |
Walter Dnes <waltdnes@××××××××.org> |
| 51 |
I don't run "desktop environments"; I run useful applications |
Archives