On Sun, Mar 30, 2008 at 04:20:57AM +0100, Ciaran McCreesh wrote: > On Sat, 29 Mar 2008 20:12:37 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > What this email is about is the inconsistancy allowed on disk and the > > fact explicitly leaving -r0 out of on disk name thus far seems to be > > an unofficial gentoo-x86 standard. > > 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 you attempted to do in splitting PMS was to force certain technical tweaks through because frankly, they made sense (or you were stubborn, and it mostly made sense). That's fine. Bearing that in mind, there is no reason to have a format definition for ebuild trees and to leave gotchas in it where they can be easily 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. > > > > Stating that each cpv in a repo must be unique ignores that there are > > multiple ways to specify certain cpv's due to implicit 0 (both suffix > > and rev). Frankly it's pretty stupid to state "it must be unique" > > while allowing multiple ways for people to screw up and violate that > > constraint. > > > > Intentionally allowing gotchas is dumb behaviour- removal of the > > gotcha is the intention here. > > 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 gentoo wise seeing a -r0 on disk (not rhetoric, literally the truth). Checking the tree for suffixes, specifically for explicit on disk 0 (_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 at the commiters behind the explict 0 suffixes, you don't see any maintainer actually repeat it in another pkg- personally, I suspect majority of it was new dev mistake, in some cases propagated (wschlich feel free to correct me on this sine you've got the most there). For dvd95, well aware pylon wasn't new at that point, so theory doesn't quite hold there (although oversight may fly). Of the ones above, only one I even vaguely recall a reason being given for suffix0 was ntp- mirroring upstream versioning roughly (vapier, please correct me if I'm wrong). Beneficial perhaps, but one single "yeah that's slightly nicer" case doesn't mean it's best for the majority. > You don't want to start breaking people who use >=..._alpha0 when > the version in the tree uses plain _alpha, for example. Explicitly requiring on disk to not specify implicit components in no way breaks atom support, or anything else for that matter. Either this is a minor brain fart on your part, or again, you're going to have to be a fair bit more clear in your explanation. > Package managers have to deal with this kind of thing, and it's > not one of those areas where we can change reality with little or > no impact. While package managers have to deal with this, there are two strong args for forcing such a change into the repo itself; 1) it is a far simpler rule for devs to keep straight, and for managers to track for violations. Instead of checking for 1.0 when 1.0-r0 is found, seeing 1.0-r0 is an error. Clear, concise, simple; meaning folks are less likely to screw it up. 2) not surprisingly, it actually simplifies manager implementation. Tracking internally whether 1.0 is actually 1.0-r0 on disk or not means extra level of mappings required, meaning more areas to screw it up. Basically, this particular problem has always been a thorn; I may be missing something, but I've yet to see any strong scenarios for why this gotcha should be allowed to exist on disk- adding explicit rules blocking it in the ondisk format itself has several benefits as laid out above, and is already pretty much the unofficial policy standard. Essentially, the "we don't mandate policy in PMS" is ignoring the technical benefits of doing this- provide a technical reason against it, and I'd be game. That said, calling it policy when it's a dumb gotcha that has benefits for elimination is ducking the issue imo. ~harring
pgpbo5zwCyvd3.pgp
Description: PGP signature
