From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Jg2FF-0007Pp-Sm for garchives@archives.gentoo.org; Sun, 30 Mar 2008 18:27:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 14B30E01B8; Sun, 30 Mar 2008 18:27:04 +0000 (UTC) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.228]) by pigeon.gentoo.org (Postfix) with ESMTP id AC16DE01B8 for ; Sun, 30 Mar 2008 18:27:03 +0000 (UTC) Received: by hu-out-0506.google.com with SMTP id 23so3209065huc.1 for ; Sun, 30 Mar 2008 11:27:03 -0700 (PDT) Received: by 10.78.81.20 with SMTP id e20mr17161787hub.64.1206901622263; Sun, 30 Mar 2008 11:27:02 -0700 (PDT) Received: from snowcone ( [213.121.151.206]) by mx.google.com with ESMTPS id o36sm2550326hub.28.2008.03.30.11.27.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Mar 2008 11:27:01 -0700 (PDT) Date: Sun, 30 Mar 2008 19:26:52 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] explicit -r0 in ebuild filename Message-ID: <20080330192652.659d7d82@snowcone> In-Reply-To: <20080330093946.GA9305@seldon.hsd1.ca.comcast.net> References: <20080330023902.GA8787@seldon.hsd1.ca.comcast.net> <20080330034811.39942523@snowcone> <20080330031237.GA8925@seldon.hsd1.ca.comcast.net> <20080330042057.089d0f8e@snowcone> <20080330041651.GA9041@seldon.hsd1.ca.comcast.net> <20080330054044.780dd65e@snowcone> <20080330093946.GA9305@seldon.hsd1.ca.comcast.net> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; 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; boundary="Sig_/+Dnu0k+WpAHjNOHM5R7QVO_"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 88bb1c26-2099-494e-9ac1-4f56989ff9ab X-Archives-Hash: db4aca5e5c86933eda10851a7ae87938 --Sig_/+Dnu0k+WpAHjNOHM5R7QVO_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Mar 2008 02:39:46 -0700 Brian Harring wrote: > I'm unaware of any suffix *currently* that has some long time usage that= =20 > is used by a mere .06% of the tree. LZMA likely would apply, but > that also was introduced rather recent so isn't exactly > representative. 7z. > Finally, drawing parallels between unpack and forcing a specific form=20 > of suffix makes no sense- dropping a format from unpack has real > world consequences, specifically breakage. Forcing "one or the > other" suffix wise is a quick inspection of 15 ebuilds in gentoo-x86, > and minor compat code if the package manager upstream wants to be > friendly to the minority of users it may affect if they make suffix0 > an error when dealing with vdb. Getting fifteen ebuilds changed might be something you could get done via QA, but it's not PMS's job. (Unless it's something really annoying, of course...) > There are lots of things that upstream does with versioning that=20 > doesn't map perfectly into ebuild versioning scheme- and that's=20 > actually quite fine. Sure, but arbitrarily banning even more of them is wrong. > Besides, this discussion is *not* about banning _pre0, or _alpha0-=20 > it's about banning explicit usage of implicit version components in=20 > the on disk ebuild. >=20 > Phrasing another way, it's pointless to have > dev-util/diffball/diffball-1.0_alpha0.ebuild ; > dev-util/diffball/diffball-1.0_alpha.ebuild=20 >=20 > is the exact same version. But a different PV. > Banning _suffix0 (and -r0) loses nothing, but gains consistancy in > on disk naming (thus less likely for devs to screw up as occured > today), and simplifies working with ebuilds on disk for managers/repo > modifiers. And means people need to start using versionator. > > Introducing multiple sets of versioning rules is a far worse gotcha > > than a ban on duplicates. Banning _alpha etc in some places but not > > others gets very confusing very quickly. >=20 > You're reaching. Nothing is lost here. What you're arguing for is=20 > thus-=20 >=20 > "you can have name the ebuild either pkg-1.0_alpha0.ebuild, or=20 > pkg-1.0_alpha.ebuild. You must not have both on disk however" >=20 > versus >=20 > "you must name the ebuild pkg-1.0_alpha.ebuild." >=20 > There is no "multiple sets of versioning rules" here, the versioning=20 > rules stay *exactly* the same. All that's being done is that the=20 > unique cpv constraint is pushed down to the on disk repository level,=20 > thus removing the issue permenentaly (while increasing consistancy=20 > across repos). But you're not pushing a unique CPV constraint unless you start banning all sorts of other things. > As I've done in attempting to respond to your=20 > questions/counterargument, please site examples/data, or at the very=20 > least be explicit about what you're claiming. I know the versioning=20 > rules (unfortunately) quite well, and there is no 'multiple sets'=20 > introduced via this change- so either you're confused, or you see=20 > something I don't. >=20 > Saves both of us a lot of time if you're explicit. You're talking about forcing one lot of rules for on-disk packages and another lot of rules for versions in general. > > The package manager has to deal with equality and equivalence > > separately anyway... If you're storing 1.0 when the actual version > > is 1.0-r0 you have issues regardless of whether -r0 itself is > > banned on disk >=20 > You're pretty clearly missing the point. When I state "it makes=20 > repository/package manager operations simpler", this is a classic=20 > example- you don't have to worry about whether or not it was -r0 on=20 > disk, or was revisionless. Via forcing consistancy into the spec, > you force it to be one or the other. No! Even ignoring -r0, you still have to know whether it's 010 or 10 on disk. Or do you want to ban that too? And all the other possible ways of having multiple equivalent but non-equal versions? > > -- if you want to prevent that, you have to start banning versions > > like 086 and 1.00 too. >=20 > No need to ban 1.00; it's already banned by PMS- quoting from=20 > names.tex: >=20 > A version starts with the number part, which is in the form=20 > \t{[0-9]+($\backslash$.[0-9]+)*} (a positive > integer, followed by zero or more dot-prefixed positive integers). >=20 > Note the 'positive integers'; so 1.00 is actually blocked by PMS. =20 > That said, that same text seems to invalidly ban 1.0 also. Zero is a positive integer! We'd've said 'natural' if we wanted to ban zero... Having said that, send a patch if you think we should cater to people using other definitions. --=20 Ciaran McCreesh --Sig_/+Dnu0k+WpAHjNOHM5R7QVO_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH79tw96zL6DUtXhERAiFOAJ9+1h6CmeXVdGJ+X2nlf5OQqnveFgCgh7PE WZGv7wSA+aGKVt2QNft0Jc4= =z06M -----END PGP SIGNATURE----- --Sig_/+Dnu0k+WpAHjNOHM5R7QVO_-- -- gentoo-dev@lists.gentoo.org mailing list