From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-project+bounces-261-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1JHfDs-00026o-99
	for garchives@archives.gentoo.org; Wed, 23 Jan 2008 13:00:56 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id DF33EE04E6;
	Wed, 23 Jan 2008 13:00:54 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id 975EFE04E6
	for <gentoo-project@lists.gentoo.org>; Wed, 23 Jan 2008 13:00:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by smtp.gentoo.org (Postfix) with ESMTP id 314A265808
	for <gentoo-project@lists.gentoo.org>; Wed, 23 Jan 2008 13:00:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -0.284
X-Spam-Level: 
X-Spam-Status: No, score=-0.284 required=5.5 tests=[AWL=0.248,
	BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067]
Received: from smtp.gentoo.org ([127.0.0.1])
	by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id X5WD4-0l2xCf for <gentoo-project@lists.gentoo.org>;
	Wed, 23 Jan 2008 13:00:45 +0000 (UTC)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.gentoo.org (Postfix) with ESMTP id 52B7A6558C
	for <gentoo-project@gentoo.org>; Wed, 23 Jan 2008 13:00:44 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1JHfDW-00073n-PD
	for gentoo-project@gentoo.org; Wed, 23 Jan 2008 13:00:34 +0000
Received: from 82.152.203.108 ([82.152.203.108])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <gentoo-project@gentoo.org>; Wed, 23 Jan 2008 13:00:34 +0000
Received: from slong by 82.152.203.108 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <gentoo-project@gentoo.org>; Wed, 23 Jan 2008 13:00:34 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-project@lists.gentoo.org
From:  Steve Long <slong@rathaus.eclipse.co.uk>
Subject: [gentoo-project]  Re: Re: Plan, then communicate
Date:  Wed, 23 Jan 2008 13:07:26 +0000
Message-ID:  <fn7dpb$pcc$1@ger.gmane.org>
References:  <20080120215706.GA16357@redwoodscientific.com> <b41005390801201455w241b8832wcc77da934c4edfb7@mail.gmail.com> <20080120233809.GA18052@redwoodscientific.com> <200801201908.07265.vapier@gentoo.org> <20080121015439.GA18636@redwoodscientific.com> <b41005390801201932y37cd2978y1e5be8becd1a1c91@mail.gmail.com> <20080121193103.GA29429@redwoodscientific.com> <4795580D.9090602@gentoo.org> <20080122044540.GA11340@redwoodscientific.com> <4796241C.7000409@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 82.152.203.108
User-Agent: KNode/0.10.4
Sender: news <news@ger.gmane.org>
X-Archives-Salt: 7bc932a0-f55b-452b-9700-2565472b6095
X-Archives-Hash: a237ea105bcaf71e7a8142d075ecfe59

Richard Freeman wrote:

> John Lawles wrote:
>> 
>>      The concept is that there would be a separate team maintaining
>> the stable tree.  A precedent for this would be the Linux kernel's
>> two-track development.
>> 
> 
> Actually, in theory that is what already happens with stable keywording
> - or is supposed to happen.  It is a different group of developers who
> maintain the stable tree (well, there is overlap, but some people wear
> multiple hats).
>
I agree that what with unstable, stable and herds working in overlays, we
have enough structure in place. Indeed some users complain that use of
overlays means they have to add stuff to layman to get bleeding-edge like
they "used to." :roll: IMO the balance is right. For anyone who hasn't
tried it yet, I recommend autounmask -n.

> Expat was a real mess - mainly because they break ABI and it doesn't use
> slotting.  I'm not sure why slotting couldn't have been used in this
> case (others might be able to comment on this).
> 
> What we need is a better mechanism of warning users that they're about
> to do something that could cause them major headaches.  ELOG is useless
> when you find out after the fact.
>
Well, we added /etc/warning to update[1] after the expat thing so we could
automatically protect users from ABI breakages. (That's why it took 2 or 3
months to bring out the new version; testing in chroot was a pita til we
got binhosts working nicely over the web.) It also picks up on any
elog/warn/info that tells the user to revdep on a lib; from a fresh 2007.0
install when it does the expat thing it also picks up on libintl.so.7
(iirc) which isn't in the warning file.

That's basically a mechanism for us to do what John was discussing: pick up
on breakages that hit us in #gentoo or -chat, and if they're more than a
simple revdep, codify a workaround. It's a generic mechanism, to do with
packages that must be built before the package (none atm) straight after
(eg gettext XML-Parser and libtool for expat), things we know will break
and so should be rebuilt before the revdep (eg dbus) and the actual lib/s
to revdep on. For all of these, they're only rebuilt if installed and
slotting is checked.

It's far easier doing that (and a whole load of other stuff) in a script
imo, since it's easy for users to change without requiring dev time. It
also keeps a logical separation between the front-end UI and the actual
package manager, which is rightly more concerned about maintaining your
system's packages in a coherent state, and building literally any type of
software.

> revdep-rebuild working better would also be nice.  If it won't work the
> ebuild should abort prior to install with a link to a document
> indicating what will need to be done, and then users can read and
> understand it before they break things.
>
Yeah that was the real problem with expat: revdep was going through a
rewrite at the time. The change so that the new version would install the
best-visible by default (as opposed to exact same versions) was fine (it's
what update does by default, since you sometimes need a package where the
version installed has gone from the tree) but it affected the apache2
upgrade since apxs is slotted. (Sorting that out added another week or
so ;)

[1] YAF update script: http://forums.gentoo.org/viewtopic-t-546828.html


-- 
gentoo-project@lists.gentoo.org mailing list