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 1M9leq-0002CF-QR for garchives@archives.gentoo.org; Thu, 28 May 2009 19:52:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CCED3E054C; Thu, 28 May 2009 19:52:55 +0000 (UTC) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by pigeon.gentoo.org (Postfix) with ESMTP id 74153E054C for ; Thu, 28 May 2009 19:52:55 +0000 (UTC) Received: by ewy9 with SMTP id 9so5254263ewy.34 for ; Thu, 28 May 2009 12:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=EEhlSqrvb9uH+0emk91nQ3dip94hTfbo7fm2lYrR1MA=; b=EknVoihjwCp9QQnEmNtGeMFcu6YjoAQaZcy/Jcy00um+xTOoGFUhKmPI/nmw4qzyQX 83MTfs3rbAKPDAtmZzdiHgHG0PeoqLIZ8ATxwr4cbg9WG5rw5H0pce+o74CoI+0wmb8s JZRTKNuyDAZEQDcg3c8BNOu2yzt6u0IoWPH5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Vb3GeLNuj6zsnWCBgqVv5MrximXnx50y8ce3KykNjpBj5blbs8VhZUA/46njjrEM2K /j0qXJeOU4NLqb1CfM/p9ATGSgl780nmxO0X7vsxA+0+xeLXGPl67RWiHkxyqlHebQnx oM+wWodthBGzqxMTZsNwrANsKJ08zqOy2an+w= Received: by 10.210.43.10 with SMTP id q10mr3243447ebq.17.1243540374669; Thu, 28 May 2009 12:52:54 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 28sm804791eyg.54.2009.05.28.12.52.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 May 2009 12:52:54 -0700 (PDT) Date: Thu, 28 May 2009 20:52:49 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 Message-ID: <20090528205249.3b830f5d@snowcone> In-Reply-To: <200905282146.48457.patrick@gentoo.org> References: <1243489596.10450.24.camel@localhost> <200905282119.35666.patrick@gentoo.org> <20090528202643.0d763768@snowcone> <200905282146.48457.patrick@gentoo.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/790wTXL5bA.c96IucNHV9Kh"; protocol="application/pgp-signature" X-Archives-Salt: 75806d01-4f3b-4cb4-8692-43a8e914dc12 X-Archives-Hash: 8b00a8dc1b06a7f6007040cac44607d8 --Sig_/790wTXL5bA.c96IucNHV9Kh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. > 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". > > 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, which has already been debunked to death... > > 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. What we are suggesting is making changes to match sensible and reasonable upstream versions. --=20 Ciaran McCreesh --Sig_/790wTXL5bA.c96IucNHV9Kh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoe65QACgkQ96zL6DUtXhHjtACeJyPmDaMT4mbOImTnSEl0SFEH db0AmwcAz/XXtC/bll9+3aJrOCOC9jWp =YCst -----END PGP SIGNATURE----- --Sig_/790wTXL5bA.c96IucNHV9Kh--