Re: Guidelines docs on ftp.debian.org.
> I think we should have a revision field. I see the following advantages
>
> * consistency as all our package names will look similar; this is
> quite a goal for a distribution
But more visual than functional.
>
> * easier handling for parsing etc
Having only a version field with a version and perhaps a hyphen followed
by a revision part isn't that difficult to parse. Having version and
revision splitted in two fields isn't very difficult but more difficult
than having this information in one (always present) version field.
> * safer design: I use -revision on debian-only packages because I
> know how easy it it to screw in the package *management*, as
> opposed to the package *content*. Why should I increase the
> version number if the content hasn't changed but only the
> packaging?
You shouldn't increase the version number if only the packaging changed,
Specific debian only packages don't have much changes with the packaging
Not at this moment. If the maintainer of such a package decides that he/she
wants to change only the packaging he/she might add a revision part and
remove it again with the next upgrade. I don't see what might be wrong
with that.
>
> Don't forget that package numbering isn't even consistent withing the rather
> well defined set of GNU programs. I see emacs 19.30 but bash-1.14.6, ie a
> scheme a.b.c and a scheme a.b.
>
If these number a going up in a normal way this will not cause any problems,
only adding characters might cause problems.
> I think that dpkg for example, even though it looks like a.b.c, really
> numbers as a.b-revision. Whenever Ian overlooks something at compile time (as
> opposed to a new major function, ie the jumps from 0.93.x to 1.0.x to 1.1.x),
> he increases the last number which hence is a *de facto revision field*.
>
I don't look in the kitchen of Ian J that much but I think he is using the
last field as a patch field. That is what it should be used for. The patches
he does aren't packaging related, they are program related (so it would not
be right to increment the revision field here), more because he isn't
changing anything related to the debianizations process as it is.
> So why the heck can't we standardize this? We still have degrees of freedom
> between the a.b-rev and a.b.c-rev scheme, no?
>
Because there isn't any need to do so, You can relate on having a version
field available (at least after all packages are updated properly), it
seems enough to me.
--
Erick Branderhorst@heel.fgg.eur.nl +31-10-4635142
Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Reply to: