[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Reminder: ALLARCHES
From:       waltdnes () waltdnes ! org
Date:       2016-05-04 19:43:15
Message-ID: 20160504194315.GA1748 () waltdnes ! org
[Download RAW message or body]

On Tue, May 03, 2016 at 09:46:10PM -0700, Matt Turner wrote
> On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> > On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> >> The solution is to have people with an actual interest in a specific
> >> architecture determine whether stabilising a package is viable, and
> >> taking sensible action, like dropping stable keywords where applicable.
> >
> > If these people do not actually exist or are not doing their job by
> > culling the depgraph appropriately, we should really drop a number of
> > archs from "stable" status.
> 
> I mostly agree, modulo the comment about people "doing their jobs".
> Arch testing completely sucks.
> 
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.
> 
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually
> significantly better than the alternative of dropping them to
> unstable.

  Matt points out a problem with the current situation.  There are
basically 2 levels of unstable...

1) Ancient or really new stuff that doesn't compile, let alone run, in
the presence of current libraries.

2) Stuff that actually works, but the devs have not stabilized it yet.

  People who accept unstable ~arch generally want the second group, but
going all out ~arch brings in builds from the first group, which breaks
systems.  The way to get "the best of both worlds" is to start with
stable, and only keyword stuff that you need, which is hopefully in the
second group.  That can get painfull with multiple dependancies,
requiring re-iterative multiple runs and keywording.  Can I make a
suggestion here?  Is it possible for the devs to come up with with...

emerge --keyword-write

... similar to "emerge --autounmask-write", but have it write to
package.accept_keywords, rather than package.unmask?

  That would achieve the effect that people are looking for, with less
work.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[prev in list] [next in list] [prev in thread] [next in thread]