From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26377 invoked by uid 1002); 6 Sep 2003 01:43:23 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 13409 invoked from network); 6 Sep 2003 01:43:23 -0000 Date: Sat, 6 Sep 2003 03:50:00 +0200 From: Thomas de Grenier de Latour To: gentoo-dev@gentoo.org Message-Id: <20030906035000.17fcce74.degrenier@easyconnect.fr> In-Reply-To: <200309060017.43415.luke-jr@gentoo.org> References: <200309041251.49718.vapier@gentoo.org> <1062749703.2935.1.camel@biproc> <20030905203951.6b60abed.degrenier@easyconnect.fr> <200309060017.43415.luke-jr@gentoo.org> Organization: Fasmz X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Re: [gentoo-core] Breaking up the beast known as app-games X-Archives-Salt: 4b23d15b-62f1-4cae-95f7-127167fdba42 X-Archives-Hash: 3acc2201a67864ef627f8e6a96209a47 Just to make it clear, I also think a tree reorganisation is needed and there has been some good ideas here (my preference goes to the flat repository with multiple informative categories inside ebuilds, as proposed by Jean Jordaan). My point is only that this is something that has to be thought early enough to avoid forgeting any user when it comes real. On Sat, 6 Sep 2003 00:17:29 +0000 Luke-Jr wrote: > Would it be possible to require a real user to run the 'emerge world' > and say "yes" to a question? If "emerge world" still works after the tree reorganisation, then there is no backward compatibility issue. But it doesn't seem so obvious to me: with many of the solution suggested so far, a current portage would not even pass the dep caching that comes after the sync. > If stdin cannot be opened (cron job), send root@localhost a mail. Doesn't change the fact that the best a current version portage can do is to inform you that a new version is available. If I do my next sync in six month in my 486 gateway because of a new openssh bug, I shouldn't be blocked only because I've ignored this information. > Having two trees would require every package change to be done on each > tree... Just as complex, I'd think. There would be no need to maintain the old tree, but only to keep something that is enough for people to make the transition (at least new portage and his deps). This plus a mechanism to force portage upgrade when really needed would be enough. -- TGL. -- gentoo-dev@gentoo.org mailing list