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 1M9lYx-0001Cw-DY for garchives@archives.gentoo.org; Thu, 28 May 2009 19:46:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C712CE0145; Thu, 28 May 2009 19:46:49 +0000 (UTC) Received: from dev.gentooexperimental.org (dev.gentooexperimental.org [81.93.240.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 89B76E0145 for ; Thu, 28 May 2009 19:46:49 +0000 (UTC) Received: from lolcathost.localnet (xdsl-87-79-233-251.netcologne.de [87.79.233.251]) by dev.gentooexperimental.org (Postfix) with ESMTP id 0929562D6DA for ; Thu, 28 May 2009 21:46:48 +0200 (CEST) From: Patrick Lauer To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 Date: Thu, 28 May 2009 21:46:48 +0200 User-Agent: KMail/1.11.90 (Linux/2.6.30-rc6-git7; KDE/4.2.88; x86_64; ; ) References: <1243489596.10450.24.camel@localhost> <200905282119.35666.patrick@gentoo.org> <20090528202643.0d763768@snowcone> In-Reply-To: <20090528202643.0d763768@snowcone> 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 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200905282146.48457.patrick@gentoo.org> X-Archives-Salt: 855a60ed-fe7d-404e-acc2-4849d408421e X-Archives-Hash: 8b67730572c97effbe98c8da5c30f7b0 On Thursday 28 May 2009 21:26:43 Ciaran McCreesh wrote: > On Thu, 28 May 2009 21:19:35 +0200 > > Patrick Lauer wrote: > > You know, usually snipping away everything else is a bit evil because > > it removes context, but in this case I just want to point out one or > > two little pieces ... > > Because you know fine well I'm right, but want to carry on trying to > derail progress? That's an interesting concept. But you know as well as I do that it isn't so, thus we have to classify your statement as a mediocre trolling attempt. Bonus for the anticipated emotional response, but I hope you're not too upset when I don't satisfy you with some mindless flaming. This mailinglist just isn't the right place for it ... > > > > For example a readonly repository would guarantee that the cache > > > > is always consistent. > > > > > > Until someone modifies it, yes. > > > > Well. DUH. That's why it is readonly. Otherwise it wouldn't be > > readonly. > > And just how do you plan to enforce that? What measures will you take > to ensure that there's no way for developers or users to modify the > repository? I can think of many simple methods. Like a tarball with a checksum. Or a zipfile. Or a git repository. That's all implementation details. But I think we can agree without too much pain that it is possible to have a reasonably tamper-proof format that we can consider readonly for these purposes. And automatically creating it is not much different from generating rsync snapshots now. I guess, smart as you are, you knew that already. > We can't make changes because the package manager needs to know the > EAPI in order to parse versions, since once we make changes versions > will be defined in terms of EAPI. ... why? You're stating one possible scenario as the only potential solution again. That ignores the other methods that were mentioned on this mailinglist and in other places where you lurk. Please stop being so dishonest. > We want to make changes because, as has been stated several times > previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely silly > and arbitrary. See Intercal versioning. Also silly and arbitrary to avoid it, but noone has provided a proposal to accomodate nonincreasing and nonmonotonic versioning systems. I doubt you would want those allowed. > > > > It would help if you would tolerate other opinions (or even the > > > > possibility that other people may have opinions that do not agree > > > > with you). > > > > > > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb > > > look pretty. The rest is purely technical and entirely objective. > > > > I think I have pointed you a few times at objective statements > > disagreeing with your subjective opinion. I hate repeating myself. > > And yet you keep ignoring the part where GLEP 55 demonstrates > objectively that the extension solution is better than the alternatives. I really. Really. Hate repeating myself. It's so redundantly superfluously redundant. And it wastes people's time. Did I mention it is redundant?