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 1M9mef-00083u-Ib for garchives@archives.gentoo.org; Thu, 28 May 2009 20:56:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2AD94E076A; Thu, 28 May 2009 20:56:48 +0000 (UTC) Received: from dev.gentooexperimental.org (dev.gentooexperimental.org [81.93.240.53]) by pigeon.gentoo.org (Postfix) with ESMTP id DBAB7E076A for ; Thu, 28 May 2009 20:56:47 +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 6A12D62D6F1 for ; Thu, 28 May 2009 22:56:47 +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 22:56:46 +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> <200905282146.48457.patrick@gentoo.org> <20090528205249.3b830f5d@snowcone> In-Reply-To: <20090528205249.3b830f5d@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: <200905282256.46827.patrick@gentoo.org> X-Archives-Salt: fedc97b8-549b-4dff-a2f4-00a3136c665d X-Archives-Hash: 0f1ace9f6c0b6d80472469535049e5ab On Thursday 28 May 2009 21:52:49 Ciaran McCreesh wrote: > On Thu, 28 May 2009 21:46:48 +0200 > > Patrick Lauer wrote: > > > 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. > > ...which a user can modify once it's been extracted. > > > Or a zipfile. > > ...which a user can modify once it's been extracted. > > > Or a git repository. > > ...which a user can commit to without telling the package manager that > the cache is now invalid. So, basically, we can't do anything, because the universe might spontaneously decide to cease to exist. Quite scary, that. Oh, and if you break stuff it is broken. Splendid! Your random distraction at least made me giggle, but it is not relevant to the discussion of a readonly 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. > > No, I do not in the slightest bit agree that there is an easy way of > ensuring that what the package manager sees hasn't been tinkered with > by a user or developer who "just wants to try a quick change out". So things blow up. Sometimes Darwin has to do his work, especially when you climb over two fences, break open a locked metal door and discover that the Ursus arctos is, in fact, a very antisocial carnivore and not as cuddly as you thought. You cannot stop a determined user from painting himself in a corner, but you can avoid most cases of accidental damage. > > > > 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. > > No-one has provided a viable way of extending the version format that > doesn't require EAPI changes. So unless you're talking about your > "start a whole new tree" idea, Wait, I thought noone had provided a way ... except that one ... argh, cognitive dissonance detected. I'm sorry, you contradicted yourself. Please choose one option only. > which has already been debunked to > death... Weird, that didn't happen in this universe. > > > 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. > > No-one is suggesting making changes to match silly upstream versions. But I thought you just said that silly and arbitrary restrictions ... I am confused. You are in a quantum superposition state where you support both sides of an argument and only collapse your brainwave functions whenever someone tries to observe you or something ... > What we are suggesting is making changes to match sensible and > reasonable upstream versions. Which we already have. Excellent, so you agree that we don't need to change versioning. Sometimes I really like discussing with you, because after a long time you suddenly accept reason :)