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 1Jfnzi-0003yt-WF for garchives@archives.gentoo.org; Sun, 30 Mar 2008 03:14:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C794E0540; Sun, 30 Mar 2008 03:14:05 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by pigeon.gentoo.org (Postfix) with ESMTP id D0AE2E0540 for ; Sun, 30 Mar 2008 03:14:04 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id k34so1200615wah.10 for ; Sat, 29 Mar 2008 20:14:04 -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=EcqRdmWjW4uvhumF/BIdJwNVcpB+29OSIpbntaR0K5c=; b=BIKfBi5jLhndL3+8sM4ea6YUZ8fJpKeZgColyhGyGjRKszoXquVbw+feKy94WtwV+Taao6DyBp51hl2fAundyuU7HrA/kZ0bHW1G1pnFT+4QHVvLPcDJLbmqJsBp6zVjcOAEiwsXd6L3KmRNmWAsvZ9mJjJ/IZr//2Z6Rvhn9vg= 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=TQ3OxF3oEOiJhVn97rvWBErEQcD6jDOwBrMQhbEb9K6lYomuqDPjHTXt/SUaCYFBbciOYIZfzhyksdxQNZNsjXofR/teKJ5+1rbgnFSKFrZjPL8wocgwEBwm4K3RSc2LDWmtHFC7cdr40FELtYmXopIPkHAe1umQyzOH2TZeVdI= Received: by 10.114.178.1 with SMTP id a1mr7163208waf.25.1206846843708; Sat, 29 Mar 2008 20:14:03 -0700 (PDT) Received: from seldon ( [71.204.151.29]) by mx.google.com with ESMTPS id j31sm1379532waf.38.2008.03.29.20.14.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Mar 2008 20:14:02 -0700 (PDT) Date: Sat, 29 Mar 2008 20:12:37 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] explicit -r0 in ebuild filename Message-ID: <20080330031237.GA8925@seldon.hsd1.ca.comcast.net> References: <20080330023902.GA8787@seldon.hsd1.ca.comcast.net> <20080330034811.39942523@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="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20080330034811.39942523@snowcone> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: e813c26b-6347-4c46-8ee9-fb7d0e4ceb80 X-Archives-Hash: 915ee76a844c6553c7d2bc880844b11e --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Reordering the email a bit... On Sun, Mar 30, 2008 at 03:48:11AM +0100, Ciaran McCreesh wrote: > On Sat, 29 Mar 2008 19:39:02 -0700 > Brian Harring wrote: > > The reason I'm emailing -dev is to ensure there is consensus on=20 > > leaving off an explicit -r0 in the ebuild name- long term, it seems=20 > > folks always followed the rule but it needs to be codified due to=20 > > problems with uniquely identifying the ebuild in the repo. > > Please think things through before asking to have pkgcore's bugs 'fixed' > via specification next time... Suspected this angle would be raised, and I'm going to be dead clear=20 here- while pkgcore smoked out the addition to the tree (benefit of 3=20 different implementations), pkgcore shouldn't explode on it. That in=20 of itself is a pkgcore bug, and not what this thread is about. 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. > Uniquely indentifying an ebuild is an issue regardless of whether or > not -r0 is allowed. See PMS section 2.4. 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. Intentionally allowing gotchas is dumb behaviour- removal of the=20 gotcha is the intention here. > We already allow and use _alpha and _alpha0 (which > mean the same thing) and so on. Add it to the list then; purpose of this thread is to push the=20 uniqueness constraint down to the on disk repo itself, instead of=20 just doing a bit of hand waving that folks can't do it. If it's part of the on disk layout, it's an easier QA check (and=20 easier implementation per PM); KISS basically. > You'd also be forcing special-casing of > eclasses that would otherwise just use PVR in dep strings. Ironically enough, this smoked out another reason for codifying=20 explicit -r0; portage's exported PVR for '1.0-r0' is '1.0', which PMS=20 disagrees w/ portage/pkgcore on . Kind of reinforces the unofficial=20 standard angle to say the least. Either way, in combination with some abuse of versionatior, an -r0 in=20 the ebuild filename *could* make things easier for some eclass=20 hackery if PVR passed through the explicit -r0. Keyword there is 'hack' however- if you have to rely on explicit -r0=20 to make eclass/PVR abuses simpler, then it's time for some quick=20 compat code. Alternatively, time to adjust portage/pkgcore's PVR to=20 automatically force -r0 in PVR (which is a far more disruptive change=20 imo). This is presuming this is what you're referring to of course- entirely=20 possible the vagueness above is referring to something else, which=20 case please clarify/expand. ~harring --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH7wUksiLx3HvNzgcRAjT7AKDRNtvelFC8PNNH5lM1Hjk7uUQktgCaAtHK mig/ZuzuLdpeCLARP8TyaPA= =nt5F -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- -- gentoo-dev@lists.gentoo.org mailing list