[gentoo-dev] explicit -r0 in ebuild filename

[gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Recently dev-ruby/rubygems-1.1.0-r0 (explicit -r0 in ebuild name) was 
commited to mainline gentoo-x86; as far as I know, this is in conflict 
w/ long term practice of not explicitly specifying -r0 in the ebuild 
name due to the implicit -r0 addition in comparison/atom matching.
At this point, said ebuild is the only one in the tree with an 
explicit -r0 also, so I'm advocating having the -r0 dropped.

The reason I'm emailing -dev is to ensure there is consensus on 
leaving off an explicit -r0 in the ebuild name- long term, it seems 
folks always followed the rule but it needs to be codified due to 
problems with uniquely identifying the ebuild in the repo.

Expanding on that one a bit, either -r0 should be required, or it must 
be left off- reason is simple, if you had both 1.1.0 and 1.1.0-r0 in a 
repo, and due to dev-ruby/rubygems-1.1.0-r0 == dev-ruby/rubygems-1.1.0
via the implicit -r0 rule, there is no defined sorting order there.  

Literally, if both are there which version on disk the manager 
used would be indeterminant at worst, pkg manager specific at best.

I've opened a pms bug (21543) to get this corrected in docs, but 
again, emailing to ensure there is consensus- so kindly chime in as 
to which it should be.  Personally I'm for preserving the unofficial 
long term rule of dropping -r0 from the ebuild name itself, but 
y'alls show, so speak up.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Sat, 29 Mar 2008 19:39:02 -0700
Brian Harring <ferringb@gmail.com> wrote:
> The reason I'm emailing -dev is to ensure there is consensus on 
> leaving off an explicit -r0 in the ebuild name- long term, it seems 
> folks always followed the rule but it needs to be codified due to 
> problems with uniquely identifying the ebuild in the repo.

Uniquely indentifying an ebuild is an issue regardless of whether or
not -r0 is allowed. See PMS section 2.4.

Even ignoring the unique identifiers, banning explicit -r0 globally is
inconsistent anyway. We already allow and use _alpha and _alpha0 (which
mean the same thing) and so on. You'd also be forcing special-casing of
eclasses that would otherwise just use PVR in dep strings.

Please think things through before asking to have pkgcore's bugs 'fixed'
via specification next time...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

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 <ferringb@gmail.com> wrote:
> > The reason I'm emailing -dev is to ensure there is consensus on 
> > leaving off an explicit -r0 in the ebuild name- long term, it seems 
> > folks always followed the rule but it needs to be codified due to 
> > 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 
here- while pkgcore smoked out the addition to the tree (benefit of 3 
different implementations), pkgcore shouldn't explode on it.  That in 
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 
fact explicitly leaving -r0 out of on disk name thus far seems to be 
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 
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.


> 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 
uniqueness constraint down to the on disk repo itself, instead of 
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 
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 
explicit -r0; portage's exported PVR for '1.0-r0' is '1.0', which PMS 
disagrees w/ portage/pkgcore on .  Kind of reinforces the unofficial 
standard angle to say the least.

Either way, in combination with some abuse of versionatior, an -r0 in 
the ebuild filename *could* make things easier for some eclass 
hackery if PVR passed through the explicit -r0.

Keyword there is 'hack' however- if you have to rely on explicit -r0 
to make eclass/PVR abuses simpler, then it's time for some quick 
compat code.  Alternatively, time to adjust portage/pkgcore's PVR to 
automatically force -r0 in PVR (which is a far more disruptive change 
imo).

This is presuming this is what you're referring to of course- entirely 
possible the vagueness above is referring to something else, which 
case please clarify/expand.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On Sat, 29 Mar 2008 20:12:37 -0700
Brian Harring <ferringb@gmail.com> 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.)

> > 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. You don't
want to start breaking people who use >=..._alpha0 when the version in
the tree uses plain _alpha, for example. 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 5334 bytes --]

On Sun, Mar 30, 2008 at 04:20:57AM +0100, Ciaran McCreesh wrote:
> On Sat, 29 Mar 2008 20:12:37 -0700
> Brian Harring <ferringb@gmail.com> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

On Sat, 29 Mar 2008 21:16:51 -0700
Brian Harring <ferringb@gmail.com> wrote:
> 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.

Not where those things involve large tree changes...

> Fairly obvious, the suffix0 case is pretty rarely used.

It's used more than a lot of other things... Some file suffixes for
unpack are only used by a single package, for example, yet they're
still in there. Ditto for some of the utilities.

> 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).

Doesn't follow. Most upstreams don't use versions that fit an
unversioned part most of the time. You wouldn't expect to see it
repeated all over the place because in the real world it's not a very
common (but importantly, not non-existent or massively rare) issue.

> > 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.

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.

> > 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;

Repositories are already not allowed to contain duplicated versions.
That's a sufficiently strong guarantee.

> 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.

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 -- if you want to prevent that, you have to start banning versions
like 086 and 1.00 too.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 6044 bytes --]

On Sun, Mar 30, 2008 at 05:40:44AM +0100, Ciaran McCreesh wrote:
> On Sat, 29 Mar 2008 21:16:51 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > 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.
> 
> Not where those things involve large tree changes...
> 
> > Fairly obvious, the suffix0 case is pretty rarely used.
> 
> It's used more than a lot of other things... Some file suffixes for
> unpack are only used by a single package, for example, yet they're
> still in there. Ditto for some of the utilities.

This isn't relevant to the discussion at hand; besides, I'm 
unaware of any suffix *currently* that has some long time usage that 
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.

Finally, drawing parallels between unpack and forcing a specific form 
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.


> > 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).
> 
> Doesn't follow. Most upstreams don't use versions that fit an
> unversioned part most of the time. You wouldn't expect to see it
> repeated all over the place because in the real world it's not a very
> common (but importantly, not non-existent or massively rare) issue.

There are lots of things that upstream does with versioning that 
doesn't map perfectly into ebuild versioning scheme- and that's 
actually quite fine.

Besides, this discussion is *not* about banning _pre0, or _alpha0- 
it's about banning explicit usage of implicit version components in 
the on disk ebuild.

Phrasing another way, it's pointless to have
dev-util/diffball/diffball-1.0_alpha0.ebuild ;
dev-util/diffball/diffball-1.0_alpha.ebuild 

is the exact same version.  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.


> > > 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.
> 
> 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.

You're reaching.  Nothing is lost here.  What you're arguing for is 
thus- 

"you can have name the ebuild either pkg-1.0_alpha0.ebuild, or 
pkg-1.0_alpha.ebuild.  You must not have both on disk however"

versus

"you must name the ebuild pkg-1.0_alpha.ebuild."

There is no "multiple sets of versioning rules" here, the versioning 
rules stay *exactly* the same.  All that's being done is that the 
unique cpv constraint is pushed down to the on disk repository level, 
thus removing the issue permenentaly (while increasing consistancy 
across repos).

As I've done in attempting to respond to your 
questions/counterargument, please site examples/data, or at the very 
least be explicit about what you're claiming.  I know the versioning 
rules (unfortunately) quite well, and there is no 'multiple sets' 
introduced via this change- so either you're confused, or you see 
something I don't.

Saves both of us a lot of time if you're explicit.


> Repositories are already not allowed to contain duplicated versions.
> That's a sufficiently strong guarantee.
> 
> > 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.
> 
> 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

You're pretty clearly missing the point.  When I state "it makes 
repository/package manager operations simpler", this is a classic 
example- you don't have to worry about whether or not it was -r0 on 
disk, or was revisionless.  Via forcing consistancy into the spec, you 
force it to be one or the other.

There are other examples that come up from this, but you pointed out 
one of the simpler ones above that actually argue *for* the change I'm 
requesting.


>  -- if you want to prevent that, you have to start banning versions
> like 086 and 1.00 too.

No need to ban 1.00; it's already banned by PMS- quoting from 
names.tex:

A version starts with the number part, which is in the form 
\t{[0-9]+($\backslash$.[0-9]+)*} (a positive
integer, followed by zero or more dot-prefixed positive integers).

Note the 'positive integers'; so 1.00 is actually blocked by PMS.  
That said, that same text seems to invalidly ban 1.0 also.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: explicit -r0 in ebuild filename

[Duncan]

Brian Harring <ferringb@gmail.com> posted
20080330093946.GA9305@seldon.hsd1.ca.comcast.net, excerpted below, on 
Sun, 30 Mar 2008 02:39:46 -0700:

> No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
> 
> A version starts with the number part, which is in the form
> \t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
> or more dot-prefixed positive integers).
> 
> Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
> said, that same text seems to invalidly ban 1.0 also.

Well, "positive integer" as used must include zero also, or by that 
definition, 0.xx style versions would be disallowed as well.  That just 
wouldn't be sane if we're to keep anything even /close/ to upstream 
version mapping, so "positive" as used here must include 0 (and does by 
the literal ranged definition), and both 0.xx and x.00 are therefore 
defined as allowed, unless there's a further restriction elsewhere that 
hasn't been quoted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: explicit -r0 in ebuild filename

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
| Brian Harring <ferringb@gmail.com> posted
| 20080330093946.GA9305@seldon.hsd1.ca.comcast.net, excerpted below, on
| Sun, 30 Mar 2008 02:39:46 -0700:
|
|> No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
|>
|> A version starts with the number part, which is in the form
|> \t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
|> or more dot-prefixed positive integers).
|>
|> Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
|> said, that same text seems to invalidly ban 1.0 also.
|
| Well, "positive integer" as used must include zero also, or by that
| definition, 0.xx style versions would be disallowed as well.  That just
| wouldn't be sane if we're to keep anything even /close/ to upstream
| version mapping, so "positive" as used here must include 0 (and does by
| the literal ranged definition), and both 0.xx and x.00 are therefore
| defined as allowed, unless there's a further restriction elsewhere that
| hasn't been quoted.
|

"non-negative integer" must've been meant.

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfvqZAACgkQp/VmCx0OL2xPsQCbBNKtynU9aSdr3uY+x+sDt4tR
0SQAoK/sGruoV0qr8wyfB2qNPy0SzH7q
=QsyO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: explicit -r0 in ebuild filename

[Ioannis Aslanidis]

If you are asking about mathematic stright definition:

negative integer: -inf,...,-1
positive integer: 1,...,inf
natural: 0,...,inf

The group of natural numbers includes the positive integers and zero.
That is the definition in most places in the world; however, in the
United States and a few more countries, non-negative integers is how
the lot is called.


On Sun, Mar 30, 2008 at 4:54 PM, Marijn Schouten (hkBst)
<hkBst@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Duncan wrote:
> | Brian Harring <ferringb@gmail.com> posted
> | 20080330093946.GA9305@seldon.hsd1.ca.comcast.net, excerpted below, on
> | Sun, 30 Mar 2008 02:39:46 -0700:
> |
> |> No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
> |>
> |> A version starts with the number part, which is in the form
> |> \t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
> |> or more dot-prefixed positive integers).
> |>
> |> Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
> |> said, that same text seems to invalidly ban 1.0 also.
> |
> | Well, "positive integer" as used must include zero also, or by that
> | definition, 0.xx style versions would be disallowed as well.  That just
> | wouldn't be sane if we're to keep anything even /close/ to upstream
> | version mapping, so "positive" as used here must include 0 (and does by
> | the literal ranged definition), and both 0.xx and x.00 are therefore
> | defined as allowed, unless there's a further restriction elsewhere that
> | hasn't been quoted.
> |
>
> "non-negative integer" must've been meant.
>
> - --
> Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
> <http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkfvqZAACgkQp/VmCx0OL2xPsQCbBNKtynU9aSdr3uY+x+sDt4tR
> 0SQAoK/sGruoV0qr8wyfB2qNPy0SzH7q
> =QsyO
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@lists.gentoo.org mailing list
>
>



-- 
Ioannis Aslanidis

<deathwing00[at]gentoo.org> 0x47F370A0
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: explicit -r0 in ebuild filename

[Richard Freeman]

Ioannis Aslanidis wrote:
> If you are asking about mathematic stright definition:
> 
> negative integer: -inf,...,-1
> positive integer: 1,...,inf
> natural: 0,...,inf
> 
> The group of natural numbers includes the positive integers and zero.
> That is the definition in most places in the world; however, in the
> United States and a few more countries, non-negative integers is how
> the lot is called.
> 

I was going to dig back to my math minor and wax eloquent about how this 
is incorrect, but it turns out we're both right:

http://en.wikipedia.org/wiki/Natural_numbers

The natural numbers may or may not include zero depending on who's using 
the term.  That was actually news to me - my understanding is that zero 
was not considered a natural number, but it was considered a whole number.

And now that we've totally drifted off topic here I'll be quiet...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 4719 bytes --]

On Sun, 30 Mar 2008 02:39:46 -0700
Brian Harring <ferringb@gmail.com> wrote:
> I'm unaware of any suffix *currently* that has some long time usage that 
> 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 
> 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 
> doesn't map perfectly into ebuild versioning scheme- and that's 
> actually quite fine.

Sure, but arbitrarily banning even more of them is wrong.

> Besides, this discussion is *not* about banning _pre0, or _alpha0- 
> it's about banning explicit usage of implicit version components in 
> the on disk ebuild.
> 
> Phrasing another way, it's pointless to have
> dev-util/diffball/diffball-1.0_alpha0.ebuild ;
> dev-util/diffball/diffball-1.0_alpha.ebuild 
> 
> 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.
> 
> You're reaching.  Nothing is lost here.  What you're arguing for is 
> thus- 
> 
> "you can have name the ebuild either pkg-1.0_alpha0.ebuild, or 
> pkg-1.0_alpha.ebuild.  You must not have both on disk however"
> 
> versus
> 
> "you must name the ebuild pkg-1.0_alpha.ebuild."
> 
> There is no "multiple sets of versioning rules" here, the versioning 
> rules stay *exactly* the same.  All that's being done is that the 
> unique cpv constraint is pushed down to the on disk repository level, 
> thus removing the issue permenentaly (while increasing consistancy 
> 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 
> questions/counterargument, please site examples/data, or at the very 
> least be explicit about what you're claiming.  I know the versioning 
> rules (unfortunately) quite well, and there is no 'multiple sets' 
> introduced via this change- so either you're confused, or you see 
> something I don't.
> 
> 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
> 
> You're pretty clearly missing the point.  When I state "it makes 
> repository/package manager operations simpler", this is a classic 
> example- you don't have to worry about whether or not it was -r0 on 
> 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.
> 
> No need to ban 1.00; it's already banned by PMS- quoting from 
> names.tex:
> 
> A version starts with the number part, which is in the form 
> \t{[0-9]+($\backslash$.[0-9]+)*} (a positive
> integer, followed by zero or more dot-prefixed positive integers).
> 
> Note the 'positive integers'; so 1.00 is actually blocked by PMS.  
> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Saturday 29 March 2008, Ciaran McCreesh wrote:
> Brian Harring <ferringb@gmail.com> wrote:
> > The reason I'm emailing -dev is to ensure there is consensus on
> > leaving off an explicit -r0 in the ebuild name- long term, it seems
> > folks always followed the rule but it needs to be codified due to
> > problems with uniquely identifying the ebuild in the repo.
>
> Even ignoring the unique identifiers, banning explicit -r0 globally is
> inconsistent anyway. We already allow and use _alpha and _alpha0 (which
> mean the same thing) and so on.

those arent the same thing.  -r# is a Gentoo-specific revision marking.  
_alpha/_rc/etc... are used to track upstream.  if upstream uses _alpha0, then 
it makes our lives easier to also use _alpha0.  -r0 has no benefit and it 
isnt inconsistent as that portion of the version is for Gentoo use only.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Sun, 30 Mar 2008 12:24:10 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> those arent the same thing.  -r# is a Gentoo-specific revision
> marking. _alpha/_rc/etc... are used to track upstream.  if upstream
> uses _alpha0, then it makes our lives easier to also use _alpha0.
> -r0 has no benefit and it isnt inconsistent as that portion of the
> version is for Gentoo use only.

Every other part allows the magic 0 behaviour. Banning it for one part
only is another one of those 'special case' rules we're trying to avoid
because no-one knows them.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Sunday 30 March 2008, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > those arent the same thing.  -r# is a Gentoo-specific revision
> > marking. _alpha/_rc/etc... are used to track upstream.  if upstream
> > uses _alpha0, then it makes our lives easier to also use _alpha0.
> > -r0 has no benefit and it isnt inconsistent as that portion of the
> > version is for Gentoo use only.
>
> Every other part allows the magic 0 behaviour. Banning it for one part
> only is another one of those 'special case' rules we're trying to avoid
> because no-one knows them.

i dont particularly care about -r0, i'm just stating that banning 
_alpha0/etc... is not acceptable.  besides, enforcing no -r0 in the tree is 
easy to do with a server side hook.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Sun, Mar 30, 2008 at 02:59:39PM -0400, Mike Frysinger wrote:
> On Sunday 30 March 2008, Ciaran McCreesh wrote:
> > Mike Frysinger <vapier@gentoo.org> wrote:
> > > those arent the same thing.  -r# is a Gentoo-specific revision
> > > marking. _alpha/_rc/etc... are used to track upstream.  if upstream
> > > uses _alpha0, then it makes our lives easier to also use _alpha0.
> > > -r0 has no benefit and it isnt inconsistent as that portion of the
> > > version is for Gentoo use only.
> >
> > Every other part allows the magic 0 behaviour. Banning it for one part
> > only is another one of those 'special case' rules we're trying to avoid
> > because no-one knows them.
> 
> i dont particularly care about -r0, i'm just stating that banning 
> _alpha0/etc... is not acceptable.

Lay out your reasons please; the meaning doesn't differ (same version 
due to implicit 0 after all), and as I've pointed out an extreme 
minority are affected.  Basically, looking to lock it down from a 
consistancy standpoint- in light of that, and that 15 ebuilds are 
affected out of ~24242, it's not seeming like it's losing much.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Sun, 30 Mar 2008 16:40:46 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > i dont particularly care about -r0, i'm just stating that banning 
> > _alpha0/etc... is not acceptable.
> 
> Lay out your reasons please; the meaning doesn't differ (same version 
> due to implicit 0 after all)

But the PV does.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Mon, Mar 31, 2008 at 12:46:33AM +0100, Ciaran McCreesh wrote:
> On Sun, 30 Mar 2008 16:40:46 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > i dont particularly care about -r0, i'm just stating that banning 
> > > _alpha0/etc... is not acceptable.
> > 
> > Lay out your reasons please; the meaning doesn't differ (same version 
> > due to implicit 0 after all)
> 
> But the PV does.

PV varying first of all, isn't incredibly grand from where I'm 
sitting- yet more any versionator style code has to account for.  
Second, so what?  We're talking about 15 ebuilds here.  It's not as 
though the ebuilds are completely screwed in this- dealing with the PV 
change for the ebuild is pretty minor.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Sun, 30 Mar 2008 17:02:16 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > But the PV does.
> 
> PV varying first of all, isn't incredibly grand from where I'm 
> sitting- yet more any versionator style code has to account for.  
> Second, so what?  We're talking about 15 ebuilds here.  It's not as 
> though the ebuilds are completely screwed in this- dealing with the
> PV change for the ebuild is pretty minor.

But pointless, since it gives no advantage. If there were something to
be gained from what you're proposing then maybe fifteen ebuilds
wouldn't be so big a deal, but there isn't.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

On Mon, Mar 31, 2008 at 01:06:02AM +0100, Ciaran McCreesh wrote:
> On Sun, 30 Mar 2008 17:02:16 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > But the PV does.
> > 
> > PV varying first of all, isn't incredibly grand from where I'm 
> > sitting- yet more any versionator style code has to account for.  
> > Second, so what?  We're talking about 15 ebuilds here.  It's not as 
> > though the ebuilds are completely screwed in this- dealing with the
> > PV change for the ebuild is pretty minor.
> 
> But pointless, since it gives no advantage. If there were something to
> be gained from what you're proposing then maybe fifteen ebuilds
> wouldn't be so big a deal, but there isn't.

Conversation is going pretty cyclical, so unless *new* points are 
brought up, I'll be waiting for new commentary.

Going to reiterate this one more time; the proposal is simple enough; 
if it's an implicit 0 via cpv parsing, it should *not* be explicitly 
specified on disk.  'diffball-1.0_alpha0.ebuild' can just as easily be 
specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can 
just as easily be specified as 'diffball-1.0.ebuild'.

Reiterating the gain: consistancy on disk, consistancy in dealing with 
PV/PVR.  As you keep point out, PV does vary- having the results of 
ebuild execution change depending on whether or not you name your 
ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is 
*not* a feature, it is what you would classically call a "design 
misfeature".  PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of 
'1.0-r0' is yet another argument for punting explicit -r0 on disk- 
it's a gotcha, design flaw in the format.

It's a simple tweak, with no real loss of functionality (lots of 
claims, no single hard proof thus far).  As spanky has stated, there 
*is* a loss of ease of use in a small subset of ebuilds- worst case, 
.06% ebuilds.  Personally, I don't consider that minority worth 
preserving since preserving that means leaving open several gotchas in 
ebuild writing, and complicates interactions (both pm and dev).

So... there it is.  Would be rather nice to have ebuild devs weight in 
on this one, rather then just package manager monkeys also (they're 
the ones bound most by the change after all).  Laid out the advantages 
to this- kindly lay out the disadvantages, where this makes things 
worse if you're looking for a response.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Sun, 30 Mar 2008 17:29:10 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Going to reiterate this one more time; the proposal is simple enough; 
> if it's an implicit 0 via cpv parsing, it should *not* be explicitly 
> specified on disk.  'diffball-1.0_alpha0.ebuild' can just as easily
> be specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild'
> can just as easily be specified as 'diffball-1.0.ebuild'.
> 
> Reiterating the gain: consistancy on disk, consistancy in dealing
> with PV/PVR.

Consistency with what? Having _alpha on disk and in PV is just as
consistent...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] explicit -r0 in ebuild filename

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

On Monday 31 March 2008 02:29:10 Brian Harring wrote:
> Going to reiterate this one more time; the proposal is simple enough;
> if it's an implicit 0 via cpv parsing, it should *not* be explicitly
> specified on disk.  'diffball-1.0_alpha0.ebuild' can just as easily be
> specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can
> just as easily be specified as 'diffball-1.0.ebuild'.
>
> Reiterating the gain: consistancy on disk, consistancy in dealing with
> PV/PVR.  As you keep point out, PV does vary- having the results of
> ebuild execution change depending on whether or not you name your
> ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is
> *not* a feature, it is what you would classically call a "design
> misfeature".  PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of
> '1.0-r0' is yet another argument for punting explicit -r0 on disk-
> it's a gotcha, design flaw in the format.
>
> It's a simple tweak, with no real loss of functionality (lots of
> claims, no single hard proof thus far).  As spanky has stated, there
> *is* a loss of ease of use in a small subset of ebuilds- worst case,
> .06% ebuilds.  Personally, I don't consider that minority worth
> preserving since preserving that means leaving open several gotchas in
> ebuild writing, and complicates interactions (both pm and dev).
>
> So... there it is.  Would be rather nice to have ebuild devs weight in
> on this one, rather then just package manager monkeys also (they're
> the ones bound most by the change after all).  Laid out the advantages
> to this- kindly lay out the disadvantages, where this makes things
> worse if you're looking for a response.

I struggle to see the technical gain of banning -r0 while allowing _alpha0 and 
002 which have the exact same technical issue. Forcing people to hard code 
versions or use sucky substitutions such as ${PV/_alpha/_alpha0} or whatever 
you'd use to convert cpufrequtils-2 to cpufrequtils-002 is clearly a loss of 
feature.

I agree that explicit -r0 on disk isn't really useful given the current Gentoo 
policy on revision bumps. But I think we established on bug #166522 [1] that 
we don't want to make restrictions based on what is useful. Otherwise we 
should ban _alpha_beta_pre_p too...

[1] https://bugs.gentoo.org/show_bug.cgi?id=166522

-- 
Bo Andresen
Gentoo KDE Dev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Thilo Bangert]

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

> Please think things through before asking to have pkgcore's bugs
> 'fixed' via specification next time...

maybe my english language skills or social interaction qualities are 
failing me, but i find the above sentence highly offensive. 

am i too thin skinned for gentoo-dev?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Anders Ossowicki]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On 31/03/2008, Thilo Bangert <bangert@gentoo.org> wrote:
>
> > Please think things through before asking to have pkgcore's bugs
> > 'fixed' via specification next time...
>
> maybe my english language skills or social interaction qualities are
> failing me, but i find the above sentence highly offensive.


pkgcore crashes on ebuilds with explicit -r0 in the PV, which led to Brian
Harring bringing this entire discussion up in the first place. Rather than
getting pkgcore to handle -r0 correctly, he decided to try and get it banned
through the specification.

Please note, the above does not imply anything about my feelings towards the
original proposal, so please don't take it as such. I really couldn't care
less what you decide to do or not do.

am i too thin skinned for gentoo-dev?
>
> In this particular case, I'd say yes :-)

-- 
Anders Ossowicki <and@vmn.dk>

[-- Attachment #2: Type: text/html, Size: 1392 bytes --]

Re: OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Patrick Lauer]

Anders Ossowicki wrote:
> On 31/03/2008, *Thilo Bangert* <bangert@gentoo.org 
> <mailto:bangert@gentoo.org>> wrote:
>
>     > Please think things through before asking to have pkgcore's bugs
>     > 'fixed' via specification next time...
>
>     maybe my english language skills or social interaction qualities are
>     failing me, but i find the above sentence highly offensive.
>
>
> pkgcore crashes on ebuilds with explicit -r0 in the PV, which led to 
> Brian Harring bringing this entire discussion up in the first place. 
> Rather than getting pkgcore to handle -r0 correctly, he decided to try 
> and get it banned through the specification.
That bug has been adressed, still leaves the underlying problem wether 
to allow this ambiguity or not. If you have the patience to read the 
pingpong between Harring and McCreesh the current discussion is wether 
that format even makes sense, not wether a fixed bug in a third-party 
app is relevant.
>
> Please note, the above does not imply anything about my feelings 
> towards the original proposal, so please don't take it as such. I 
> really couldn't care less what you decide to do or not do.
>
>     am i too thin skinned for gentoo-dev?
>
> In this particular case, I'd say yes :-)
I'd say no. There's no need for ad hominem attack in what is supposed to 
be a technical discussion.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Anders Ossowicki]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On 31/03/2008, Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
>
> Anders Ossowicki wrote:
> > On 31/03/2008, *Thilo Bangert* <bangert@gentoo.org
>
> > <mailto:bangert@gentoo.org>> wrote:
> >
> >     > Please think things through before asking to have pkgcore's bugs
> >     > 'fixed' via specification next time...
> >
> >     maybe my english language skills or social interaction qualities are
> >     failing me, but i find the above sentence highly offensive.
> >
> >
> > pkgcore crashes on ebuilds with explicit -r0 in the PV, which led to
> > Brian Harring bringing this entire discussion up in the first place.
> > Rather than getting pkgcore to handle -r0 correctly, he decided to try
> > and get it banned through the specification.
>
> That bug has been adressed, still leaves the underlying problem wether
> to allow this ambiguity or not.


Excellent - now that light has been shed on this minor detail, I'm sure you
won't see that comment on pkgcore bugs again.

If you have the patience to read the
> pingpong between Harring and McCreesh the current discussion is wether
> that format even makes sense, not wether a fixed bug in a third-party
> app is relevant.


I'm pretty sure the aforementioned pingpong started as a result of a pkgcore
bug. Thilo referred to one of Ciaran's first replies and as such, I see no
reason to regard that reply as an ad hominem attack.

Enough, I was only replying to a question brought up by Thilo, and I do not
want to waste time on an endless discussion with other gentoo users.
-- 
Anders Ossowicki <and@vmn.dk>

[-- Attachment #2: Type: text/html, Size: 2366 bytes --]

Re: OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Jeroen Roovers]

On Mon, 31 Mar 2008 09:40:42 +0200
Thilo Bangert <bangert@gentoo.org> wrote:

> > Please think things through before asking to have pkgcore's bugs
> > 'fixed' via specification next time...
> 
> maybe my english language skills or social interaction qualities are 
> failing me, but i find the above sentence highly offensive. 

I agree. It smells of a sort of intellectual elitism that stops being
productive when information is left to be surmised instead of being
freely and generously shared.

> am i too thin skinned for gentoo-dev?

Or, what kind of community do we want to be?


Kind regards,
     JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: explicit -r0 in ebuild filename

[Michael Sterrett -Mr. Bones.-]

The ebuild howto has been clear on this topic for quite a while:

"The fourth subsection of the package name is the Gentoo Linux-specific
revision number ({-r#}). This subsection, like the suffix, is also
optional. # is a non-zero positive integer; e.g., package-4.5.3-r3"

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org

On Sat, 29 Mar 2008, Brian Harring wrote:

> Recently dev-ruby/rubygems-1.1.0-r0 (explicit -r0 in ebuild name) was
> commited to mainline gentoo-x86; as far as I know, this is in conflict
> w/ long term practice of not explicitly specifying -r0 in the ebuild
> name due to the implicit -r0 addition in comparison/atom matching.
> At this point, said ebuild is the only one in the tree with an
> explicit -r0 also, so I'm advocating having the -r0 dropped.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: explicit -r0 in ebuild filename

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Sat, 29 Mar 2008 23:36:10 -0400 (EDT)
"Michael Sterrett -Mr. Bones.-" <msterret@coat.com> wrote:
> The ebuild howto has been clear on this topic for quite a while:
> 
> "The fourth subsection of the package name is the Gentoo
> Linux-specific revision number ({-r#}). This subsection, like the
> suffix, is also optional. # is a non-zero positive integer; e.g.,
> package-4.5.3-r3"

The ebuild howto is massively out of line with the tree and with the
package managers in that entire section. Whilst the ebuild howto might
be a nice starting point, it's in no way suitable for consulting for
either tree policy or package manager policy...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]