| 1 |
Reordering the email a bit... |
| 2 |
|
| 3 |
On Sun, Mar 30, 2008 at 03:48:11AM +0100, Ciaran McCreesh wrote: |
| 4 |
> On Sat, 29 Mar 2008 19:39:02 -0700 |
| 5 |
> Brian Harring <ferringb@×××××.com> wrote: |
| 6 |
> > The reason I'm emailing -dev is to ensure there is consensus on |
| 7 |
> > leaving off an explicit -r0 in the ebuild name- long term, it seems |
| 8 |
> > folks always followed the rule but it needs to be codified due to |
| 9 |
> > problems with uniquely identifying the ebuild in the repo. |
| 10 |
> |
| 11 |
> Please think things through before asking to have pkgcore's bugs 'fixed' |
| 12 |
> via specification next time... |
| 13 |
|
| 14 |
Suspected this angle would be raised, and I'm going to be dead clear |
| 15 |
here- while pkgcore smoked out the addition to the tree (benefit of 3 |
| 16 |
different implementations), pkgcore shouldn't explode on it. That in |
| 17 |
of itself is a pkgcore bug, and not what this thread is about. |
| 18 |
|
| 19 |
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 |
| 21 |
an unofficial gentoo-x86 standard. |
| 22 |
|
| 23 |
|
| 24 |
> Uniquely indentifying an ebuild is an issue regardless of whether or |
| 25 |
> not -r0 is allowed. See PMS section 2.4. |
| 26 |
|
| 27 |
Stating that each cpv in a repo must be unique ignores that there are |
| 28 |
multiple ways to specify certain cpv's due to implicit 0 (both suffix |
| 29 |
and rev). Frankly it's pretty stupid to state "it must be unique" |
| 30 |
while allowing multiple ways for people to screw up and violate that |
| 31 |
constraint. |
| 32 |
|
| 33 |
Intentionally allowing gotchas is dumb behaviour- removal of the |
| 34 |
gotcha is the intention here. |
| 35 |
|
| 36 |
|
| 37 |
> We already allow and use _alpha and _alpha0 (which |
| 38 |
> mean the same thing) and so on. |
| 39 |
|
| 40 |
Add it to the list then; purpose of this thread is to push the |
| 41 |
uniqueness constraint down to the on disk repo itself, instead of |
| 42 |
just doing a bit of hand waving that folks can't do it. |
| 43 |
|
| 44 |
If it's part of the on disk layout, it's an easier QA check (and |
| 45 |
easier implementation per PM); KISS basically. |
| 46 |
|
| 47 |
|
| 48 |
> You'd also be forcing special-casing of |
| 49 |
> eclasses that would otherwise just use PVR in dep strings. |
| 50 |
|
| 51 |
Ironically enough, this smoked out another reason for codifying |
| 52 |
explicit -r0; portage's exported PVR for '1.0-r0' is '1.0', which PMS |
| 53 |
disagrees w/ portage/pkgcore on . Kind of reinforces the unofficial |
| 54 |
standard angle to say the least. |
| 55 |
|
| 56 |
Either way, in combination with some abuse of versionatior, an -r0 in |
| 57 |
the ebuild filename *could* make things easier for some eclass |
| 58 |
hackery if PVR passed through the explicit -r0. |
| 59 |
|
| 60 |
Keyword there is 'hack' however- if you have to rely on explicit -r0 |
| 61 |
to make eclass/PVR abuses simpler, then it's time for some quick |
| 62 |
compat code. Alternatively, time to adjust portage/pkgcore's PVR to |
| 63 |
automatically force -r0 in PVR (which is a far more disruptive change |
| 64 |
imo). |
| 65 |
|
| 66 |
This is presuming this is what you're referring to of course- entirely |
| 67 |
possible the vagueness above is referring to something else, which |
| 68 |
case please clarify/expand. |
| 69 |
|
| 70 |
~harring |
Archives