From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9SHA-00086R-9Y for garchives@archives.gentoo.org; Wed, 27 May 2009 23:11:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49FD7E038E; Wed, 27 May 2009 23:11:11 +0000 (UTC) Received: from mail-fx0-f219.google.com (mail-fx0-f219.google.com [209.85.220.219]) by pigeon.gentoo.org (Postfix) with ESMTP id E8E60E038E for ; Wed, 27 May 2009 23:11:10 +0000 (UTC) Received: by fxm19 with SMTP id 19so4576579fxm.34 for ; Wed, 27 May 2009 16:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type:content-transfer-encoding; bh=j6dg/KsgpJqHeg+V+5l3eKDIHR25woq3Hrgdi03Lydk=; b=MKz5pDQcx8BNRRMr4ixakvQ9W9mX1bvCuEc1fKnCfDr0WLU7qqIDHH9qdKNY5vwY7v +rZ8IZx/hzxp0M85qWhwHOnVnA2AaDxDruvAhctdBqE0Fhgv8ICMo9ByW4XBlLh92tcd JKaxOw/Y4ZOWGw8tR+jxJO1WktzPVXcRMHgxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=ZhuJiNekQk9p58YgrK2iEqRrAeUVjyRBC6tA1cva9eykl5ESiPrzhMMZ2MQzWlsjwf Ubrtbtm8AiUiKXrvl6U1Ye92Oy6Kt1bp70gdAyoAFAUrZDQ+f7VOSZsnEma1E0HZ9zK7 l1hHigXeykmH63KzywCM5rxMlkcPVJN8cUYF4= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: p.jaroszynski@gmail.com Received: by 10.204.100.71 with SMTP id x7mr486322bkn.130.1243465870174; Wed, 27 May 2009 16:11:10 -0700 (PDT) In-Reply-To: <200905280033.32333.patrick@gentoo.org> References: <1243454143.3480.1@NeddySeagoon> <200905272358.44171.patrick@gentoo.org> <200905280033.32333.patrick@gentoo.org> From: =?UTF-8?Q?Piotr_Jaroszy=C5=84ski?= Date: Thu, 28 May 2009 01:10:50 +0200 X-Google-Sender-Auth: fa10d4e03ee6596c Message-ID: Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5a271f99-91ef-4025-849c-ef7fb2f7099a X-Archives-Hash: 3998cc141f7c9fe27c025cc4db9227bf 2009/5/28 Patrick Lauer : > On Thursday 28 May 2009 00:12:56 Piotr Jaroszy=C5=84ski wrote: >> 2009/5/27 Patrick Lauer : >> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote: >> >> > Gentoo should not repeat the VHS vs Betamax war. For those who do n= ot >> >> > remember, VHS was the better marketed but inferior technical soluti= on >> >> > that won the standards war for domestic Video recorders. >> >> > >> >> :) =C2=A0Yep. =C2=A0And bad design decisions can haunt is for a long = time. >> > >> > Actually, once we add the current-glep55 changes we have no way of san= ely >> > undoing them if we should realize that they don't work out for us ... >> > >> > ... unless we do horrible things like forbidding it, which would cause >> > the same errors we are trying to hide now. >> > >> > So unless we have a plan for mid-term future changes I don't see why w= e >> > would want the current GLEP55 - it's a one-way change in the current >> > state. >> >> How is it one-way exactly? You can do pretty much anything you want in >> a new EAPI (that's the point). > > You cannot undo it. > > In other words, you'll have to allow stupid filenames until the end of ti= mes > even if you are quite positively sure that it is, right now, a bad idea. What do you mean by "allow" exactly? You can put whatever filenames in the tree currently and package managers ignore them, just as they would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55 be accepted, implemented and then undone you would "lose" only *.ebuild-{EAPIs introduced before undoing}. >> >> My preference is the one-time .ebuild->.eb change, and putting the EA= PI >> >> on the first line, like a #!shebang. =C2=A0Very easy to extract, and = good >> >> design. >> > >> > My preference is freezing the rsync tree, storing all referenced >> > distfiles on at least one mirror, then change the rsync path. >> > That way all "old" users get the last sane upgrade position (...) >> >> And bugs and security vulnerabilities too. Or do you propose >> maintaining multiple trees at the same time? I think one of the main >> points of EAPI was to avoid doing exactly that. > > Not at all. Just an upgrade snapshot so you can get "old" users into a kn= own > state, then let them upgrade at least the package manager to a point wher= e > they can use the rest. That snapshot should be seen as a transient helper= , not > as a "release" ... So a user n snapshots behind would have to go through various upgrade paths n times. And if she failed to do it all at once her system would be left with known bugs and vulnerabilities. Sounds a bit messy to me, especially as it can be easily avoided (with improved EAPIs - i.e. g55). --=20 Best Regards, Piotr Jaroszy=C5=84ski