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 1Jfozs-0008UN-H6 for garchives@archives.gentoo.org; Sun, 30 Mar 2008 04:18:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D6D9FE04FA; Sun, 30 Mar 2008 04:18:18 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 95BD6E04FA for ; Sun, 30 Mar 2008 04:18:18 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id k34so1225048wah.10 for ; Sat, 29 Mar 2008 21:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=OJB/pJ5y0A3/tsVJp6PMuy2svY+jXPLqdaVB3cDTuLo=; b=PpZAWSH3EAWXjKyy8sVb6xo3ZeseQe4NHIyWYdyADyf5LmT6XVNacYCd/OnJqWjLA0tOHe4QhZ38wG797BOrFq72b6PYCMAanQHY2sHgPzZ4dWUN95O1p6Jicra1Qg/X93UwBuKbD/O8Y/HR6xxLCOubb1CMeq3HDeI/sUmU59c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=nJiBQ5h6lCrymGThNbdpw4cylpv+XlPyMPWv2c6pl9CA07Cs4LySi/S6yYTFC6sA1hEqH25pmKs5uClOopzj/GsFsCB9XDuYFd42JFuzJD9IiJJ2Xx5iHQbPoRg5BzVaQEGEns0qxdoU/y2MglmryNXeLH2b7pgoY9i0pqc/cms= Received: by 10.114.146.1 with SMTP id t1mr7246484wad.20.1206850698031; Sat, 29 Mar 2008 21:18:18 -0700 (PDT) Received: from seldon ( [71.204.151.29]) by mx.google.com with ESMTPS id k23sm2835875waf.15.2008.03.29.21.18.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Mar 2008 21:18:17 -0700 (PDT) Date: Sat, 29 Mar 2008 21:16:51 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] explicit -r0 in ebuild filename Message-ID: <20080330041651.GA9041@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> 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; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20080330042057.089d0f8e@snowcone> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 13968e43-2a92-4715-b23f-d5cf75d5e636 X-Archives-Hash: b5837a489e726a78f1d0ef397f5ae411 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 30, 2008 at 04:20:57AM +0100, Ciaran McCreesh wrote: > On Sat, 29 Mar 2008 20:12:37 -0700 > Brian Harring wrote: > > What this email is about is the inconsistancy allowed on disk and the= =20 > > fact explicitly leaving -r0 out of on disk name thus far seems to be=20 > > an unofficial gentoo-x86 standard. >=20 > Which means it's not something to be specified in PMS. Devmanual, > possibly, but that's a whole different kettle of fish. (We don't > specify that you should use tabs for indenting in ebuilds in PMS > either.) Contrasting tabs vs spaces is a whole other matter. One of the things=20 you attempted to do in splitting PMS was to force certain technical=20 tweaks through because frankly, they made sense (or you were stubborn,=20 and it mostly made sense). That's fine. Bearing that in mind, there is no reason to have a format definition=20 for ebuild trees and to leave gotchas in it where they can be easily=20 addressed via simple bannination rules. > > > Uniquely indentifying an ebuild is an issue regardless of whether or > > > not -r0 is allowed. See PMS section 2.4. > >=20 > > Stating that each cpv in a repo must be unique ignores that there are= =20 > > multiple ways to specify certain cpv's due to implicit 0 (both suffix= =20 > > and rev). Frankly it's pretty stupid to state "it must be unique"=20 > > while allowing multiple ways for people to screw up and violate that=20 > > constraint. > >=20 > > Intentionally allowing gotchas is dumb behaviour- removal of the=20 > > gotcha is the intention here. >=20 > PMS is going with the tree here. There have always been equivalent but > not equal ways of specifying versions, and people use them. Thing is, people *don't*. This is the first time in my experience=20 gentoo wise seeing a -r0 on disk (not rhetoric, literally the truth). =20 Checking the tree for suffixes, specifically for explicit on disk 0=20 (_alpha0 for example): _alpha: 1 out of 82, ~1.2% dev-util/cssc-0.15_alpha0 (user address, 'bruce locke'; 2003) _beta: 1 out of 255, ~.3% dev-python/visual-4_beta0 (tercel) _pre: 4 out of 278, ~1.4% games-board/gtkboard-0.11_pre0 (msterret- bones?, 2003) media-sound/cdparanoia-3.10_pre0-r1 (drac) media-sound/cdparanoia-3.10_pre0 (drac) dev-util/larch-1.0_pre0 (rphillips, 2003) _rc: 2 out of 197, ~1% www-client/elinks-0.11.4_rc0 (spock) dev-haskell/hs-plugins-1.0_rc0 (araujo) _p: 7 out of 329, ~2.1% sys-fs/owfs-2.7_p0-r2 (wschlich) sys-fs/owfs-2.7_p0 (wschlich) sys-fs/owfs-2.7_p0-r1 (wschlich) app-cdr/dvd95-1.2_p0 (pylon) app-cdr/dvd95-1.3_p0 (pylon) media-fonts/wqy-bitmapfont-0.9.9_p0 (matsuu) net-misc/ntp-4.2.4_p0 (vapier, aka the spankster) Fairly obvious, the suffix0 case is pretty rarely used. Quick look=20 at the commiters behind the explict 0 suffixes, you don't see any=20 maintainer actually repeat it in another pkg- personally, I suspect=20 majority of it was new dev mistake, in some cases propagated (wschlich=20 feel free to correct me on this sine you've got the most there). For=20 dvd95, well aware pylon wasn't new at that point, so theory doesn't=20 quite hold there (although oversight may fly). Of the ones above, only one I even vaguely recall a reason being given=20 for suffix0 was ntp- mirroring upstream versioning roughly (vapier,=20 please correct me if I'm wrong). Beneficial perhaps, but one single=20 "yeah that's slightly nicer" case doesn't mean it's best for the=20 majority. > You don't want to start breaking people who use >=3D..._alpha0 when=20 > the version in the tree uses plain _alpha, for example. Explicitly requiring on disk to not specify implicit components in no=20 way breaks atom support, or anything else for that matter. Either=20 this is a minor brain fart on your part, or again, you're going to=20 have to be a fair bit more clear in your explanation. > Package managers have to deal with this kind of thing, and it's=20 > not one of those areas where we can change reality with little or=20 > no impact. While package managers have to deal with this, there are two strong=20 args for forcing such a change into the repo itself; 1) it is a far simpler rule for devs to keep straight, and for=20 managers to track for violations. Instead of checking for 1.0 when=20 1.0-r0 is found, seeing 1.0-r0 is an error. Clear, concise, simple;=20 meaning folks are less likely to screw it up. 2) not surprisingly, it actually simplifies manager implementation. =20 Tracking internally whether 1.0 is actually 1.0-r0 on disk or not=20 means extra level of mappings required, meaning more areas to screw it=20 up. Basically, this particular problem has always been a thorn; I may be=20 missing something, but I've yet to see any strong scenarios for why=20 this gotcha should be allowed to exist on disk- adding explicit rules=20 blocking it in the ondisk format itself has several benefits as laid=20 out above, and is already pretty much the unofficial policy standard. Essentially, the "we don't mandate policy in PMS" is ignoring the=20 technical benefits of doing this- provide a technical reason against=20 it, and I'd be game. That said, calling it policy when it's a dumb=20 gotcha that has benefits for elimination is ducking the issue imo. ~harring --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH7xQzsiLx3HvNzgcRAvdbAJ0YiOc3xP0JDegIghD0XKB8dVe9OACgqJEd dS/AbRTOEkiTHiw+xciL8QI= =e6Zi -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- -- gentoo-dev@lists.gentoo.org mailing list