Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Christian Hofstaedtler

unread,

Apr 2, 2011, 4:10:02 PM4/2/11

to

Package: dpkg
Version: 1.16.0
Severity: important
Tags: sid

Hi,

dpkg 1.16.0 appears to refuse to install packages which have a Version:
field which does not start with a digit.

The Debian policy currently states:
The upstream_version may contain only alphanumerics[33] and the
characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and *should*
start with a digit.

I don't see why this would forbid versions starting with an
anlphanumeric character.

Either dpkg should again install packages with such Version: fields, or
the policy should be changed to reflect this new requirement.

Thank you,
Christian Hofstaedtler

-- System Information:
Debian Release: 6.0.1
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Guillem Jover

unread,

Apr 2, 2011, 11:20:01 PM4/2/11

to

reassign 620566 debian-policy
severity 620566 normal
tags 620566 patch
retitle 620566 Sync upstream version format with what dpkg accepts now
thanks

On Sat, 2011-04-02 at 21:28:08 +0200, Christian Hofstaedtler wrote:
> Package: dpkg
> Version: 1.16.0
> Severity: important
> Tags: sid

> dpkg 1.16.0 appears to refuse to install packages which have a Version:

> field which does not start with a digit.

This is in line with the recent changes to properly parse and validate
the data dpkg has to handle.

> The Debian policy currently states:
> The upstream_version may contain only alphanumerics[33] and the
> characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and *should*
> start with a digit.
>
> I don't see why this would forbid versions starting with an
> anlphanumeric character.

Well, while I generally agree dpkg does not need to be as strict as
policy when it might make sense to be laxer outside Debian, in this
case I don't see the point in allowing the version to start with an
alphabetic character. This is an interface other software rely on,
and expect it to be as specified, so making sure dpkg validates and
disallows bogus values seems the correct thing to do.

> Either dpkg should again install packages with such Version: fields, or
> the policy should be changed to reflect this new requirement.

Then I guess this is a request to change the ‘should’ to a ‘must’.
Attached patch against policy master.

thanks,
guillem

policy-upstream-version-first-char.patch

Julien Cristau

unread,

Apr 3, 2011, 4:30:01 AM4/3/11

to

Full quoting because you didn't cc the policy list when reassigning...

I don't see the point in disallowing these versions in dpkg, they won't
cause any problem anywhere, they're just discouraged by policy... Maybe
we want dak to forbid them, but that's a different thing.

> > Either dpkg should again install packages with such Version: fields, or
> > the policy should be changed to reflect this new requirement.
>
> Then I guess this is a request to change the ‘should’ to a ‘must’.
> Attached patch against policy master.
>
> thanks,
> guillem

> diff --git a/policy.sgml b/policy.sgml
> index 6e04c81..ed10580 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -3125,7 +3125,7 @@ Package: libc6
> </footnote>
> and the characters <tt>.</tt> <tt>+</tt> <tt>-</tt>
> <tt>:</tt> <tt>~</tt> (full stop, plus, hyphen, colon,
> - tilde) and should start with a digit. If there is no
> + tilde) and must start with a digit. If there is no
> <var>debian_revision</var> then hyphens are not allowed;
> if there is no <var>epoch</var> then colons are not
> allowed.

Cheers,
Julien

Thorsten Glaser

unread,

Apr 3, 2011, 12:00:03 PM4/3/11

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Guillem Jover dixit…

> <tt>:</tt> <tt>~</tt> (full stop, plus, hyphen, colon,
> - tilde) and should start with a digit. If there is no
> + tilde) and must start with a digit. If there is no
> <var>debian_revision</var> then hyphens are not allowed;

+1 (especially considering how version n̲u̲m̲b̲e̲r̲ comparision works)

bye,
//mirabilos
- --
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MirBSD)

iQIVAwUBTZiTxna1NLLpkAfgAQkmCxAAkpSxV8K+E+jYAqxk7F2Ow0K2bQ/ajryr
H3shjfygxSowSHEXzuC6edkQiZfIJsFLwuMkFYDgq+HTrXgMRhWUHdVkq70Q68KW
qQkk3M6tgauRMjH/De/SIhnCSo4xUH0umNaMdaK5qaobDpssG8R/Wg68ETyr/lZy
3DfW0kMwJpaYH6MW2hiLUNiJcP0FttMqRjOd9s4kjWU6/7/rADYHr/o0yjz+lk0Q
tRebUjBuMPi/kZQHjep1jACKQjuIDU0QM/PMBuf6EerJnhJUu3GcVBCthyZAnhUW
YyEN7By2s2o+/ZBIjSSu7bvYP/hgwV4SrMx5HAqMxYzWCUvYBFfIFvmg9K3DViCB
d+YQFMP1L/bHdR0LtSmklvINCBDfDdrceF62LG6ltWEApsDWjFKSOUJgf9y7P/vv
/j9J/JYodc8pNYPuG2/KIJWH6vdlDy59TeMzFzAd2vebBdOyZ2SZ0+UBUh9nUm1u
kRf6gNy2nzmdXGmlcdAbNDvJslCOL7e++WgcyGwa7PjXspJUW83c188sDvP1GikU
oQz+1tRZbwiE+nIIuu8muukfzNibKFEMkbeoGemSn+O5Z24eSHMvMWIX/ZorixtH
+CWSF9wl3IJMflf/jxk941rx7MRCTKjQ3yAJVrLw0SoP5qb07E0maxYLv19ZBnrQ
eIu/T5T+phU=
=Ck2S
-----END PGP SIGNATURE-----

Michael Prokop

unread,

Apr 3, 2011, 5:30:02 PM4/3/11

to

* Julien Cristau [Son Apr 03, 2011 at 10:16:47 +0200]:

> On Sun, Apr 3, 2011 at 05:03:47 +0200, Guillem Jover wrote:
> > On Sat, 2011-04-02 at 21:28:08 +0200, Christian Hofstaedtler wrote:

> > > dpkg 1.16.0 appears to refuse to install packages which have a Version:
> > > field which does not start with a digit.

> > This is in line with the recent changes to properly parse and validate
> > the data dpkg has to handle.

> > > The Debian policy currently states:
> > > The upstream_version may contain only alphanumerics[33] and the
> > > characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and *should*
> > > start with a digit.

> > > I don't see why this would forbid versions starting with an
> > > anlphanumeric character.

> > Well, while I generally agree dpkg does not need to be as strict as
> > policy when it might make sense to be laxer outside Debian, in this
> > case I don't see the point in allowing the version to start with an
> > alphabetic character. This is an interface other software rely on,
> > and expect it to be as specified, so making sure dpkg validates and
> > disallows bogus values seems the correct thing to do.

> I don't see the point in disallowing these versions in dpkg, they won't
> cause any problem anywhere, they're just discouraged by policy... Maybe
> we want dak to forbid them, but that's a different thing.

Yeah, actually the change is breaking existing packages which used
to work just fine (disclaimer: no, the ones I'm talking about aren't
available in the official Debian pool).

I understand the change but a timeframe for upgrading would be nice
with warnings instead of erroring out.

regards,
-mika-

signature.asc

Russ Allbery

unread,

Apr 3, 2011, 11:20:01 PM4/3/11

to

Julien Cristau <jcri...@debian.org> writes:
> On Sun, Apr 3, 2011 at 05:03:47 +0200, Guillem Jover wrote:

>> Well, while I generally agree dpkg does not need to be as strict as
>> policy when it might make sense to be laxer outside Debian, in this
>> case I don't see the point in allowing the version to start with an
>> alphabetic character. This is an interface other software rely on, and
>> expect it to be as specified, so making sure dpkg validates and
>> disallows bogus values seems the correct thing to do.

> I don't see the point in disallowing these versions in dpkg, they won't
> cause any problem anywhere, they're just discouraged by policy... Maybe
> we want dak to forbid them, but that's a different thing.

I'm not a fan of having DAK reject things that Policy says are allowed.
The primary purpose of Policy is to document the requirements for the
Debian archive, so if the Debian archive doesn't allow something, Policy
should say that. Otherwise, it's just confusing. Out-of-archive packages
are always allowed (and sometimes expected) to ignore bits of Policy.

I think we should either allow it or not allow it, but Policy and DAK
should agree.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Russ Allbery

unread,

Apr 3, 2011, 11:30:02 PM4/3/11

to

Michael Prokop <mi...@debian.org> writes:

> Yeah, actually the change is breaking existing packages which used to
> work just fine (disclaimer: no, the ones I'm talking about aren't
> available in the official Debian pool).

> I understand the change but a timeframe for upgrading would be nice with
> warnings instead of erroring out.

I think this is more an objection to the dpkg change than to the Policy
change, correct? Policy doesn't govern out-of-archive packages, and I
think it's reasonable to just forbid version numbers starting with a
letter in the Debian archive rather than saying "should not" about
something that's syntactical.

My inclination is to second this, but I want to make sure that we've
answered your and Julien's objections first.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

--

Cyril Brulebois

unread,

Apr 3, 2011, 11:40:01 PM4/3/11

to

Russ Allbery <r...@debian.org> (03/04/2011):

> I'm not a fan of having DAK reject things that Policy says are
> allowed.

Neither am I.

> I think we should either allow it or not allow it, but Policy and
> DAK should agree.

Yes, pretty please.

KiBi.

signature.asc

Raphael Hertzog

unread,

Apr 4, 2011, 3:10:01 AM4/4/11

to

On Sun, 03 Apr 2011, Russ Allbery wrote:
> My inclination is to second this, but I want to make sure that we've
> answered your and Julien's objections first.

And for complete reference, dpkg accepts those version in
/var/lib/dpkg/status (so that dpkg still works for users with affected
packages installed) but will not a accept to install a .deb with a bad
version anymore.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

Jonathan Nieder

unread,

Apr 4, 2011, 3:30:01 AM4/4/11

to

Raphael Hertzog wrote:
> On Sun, 03 Apr 2011, Russ Allbery wrote:

>> My inclination is to second this, but I want to make sure that we've
>> answered your and Julien's objections first.
>
> And for complete reference, dpkg accepts those version in
> /var/lib/dpkg/status (so that dpkg still works for users with affected
> packages installed) but will not a accept to install a .deb with a bad
> version anymore.

One possibility would be to mandate in policy that:

1. upstream_version must start with a digit;
2. package management tools should accept an upstream_version that does

not start with a digit.

But that would be somewhat confusing in my opinion, and it might be
hard to sell (2) as something that belongs in policy. If there were a
separate packaging system manual, life would be easier. Lacking that,
I can see the potential value of dpkg validating the packages it
installs (though it's painful).

Julien Cristau

unread,

Apr 4, 2011, 5:10:02 AM4/4/11

to

On Sun, Apr 3, 2011 at 20:07:57 -0700, Russ Allbery wrote:

> Julien Cristau <jcri...@debian.org> writes:
> > On Sun, Apr 3, 2011 at 05:03:47 +0200, Guillem Jover wrote:
>
> >> Well, while I generally agree dpkg does not need to be as strict as
> >> policy when it might make sense to be laxer outside Debian, in this
> >> case I don't see the point in allowing the version to start with an
> >> alphabetic character. This is an interface other software rely on, and
> >> expect it to be as specified, so making sure dpkg validates and
> >> disallows bogus values seems the correct thing to do.
>
> > I don't see the point in disallowing these versions in dpkg, they won't
> > cause any problem anywhere, they're just discouraged by policy... Maybe
> > we want dak to forbid them, but that's a different thing.
>
> I'm not a fan of having DAK reject things that Policy says are allowed.
> The primary purpose of Policy is to document the requirements for the
> Debian archive, so if the Debian archive doesn't allow something, Policy
> should say that. Otherwise, it's just confusing. Out-of-archive packages
> are always allowed (and sometimes expected) to ignore bits of Policy.
>
> I think we should either allow it or not allow it, but Policy and DAK
> should agree.
>

Agreed, dak should only reject these names if policy does. I have no
particular opinion on the policy change, I just think the dpkg change is
wrong.

Cheers,
Julien

Michael Prokop

unread,

Apr 4, 2011, 6:00:03 AM4/4/11

to

* Russ Allbery [Sun Apr 03, 2011 at 08:12:03PM -0700]:
> Michael Prokop <mi...@debian.org> writes:

> > Yeah, actually the change is breaking existing packages which used to
> > work just fine (disclaimer: no, the ones I'm talking about aren't
> > available in the official Debian pool).

> > I understand the change but a timeframe for upgrading would be nice with
> > warnings instead of erroring out.

> I think this is more an objection to the dpkg change than to the Policy
> change, correct?

ACK

> Policy doesn't govern out-of-archive packages, and I think it's
> reasonable to just forbid version numbers starting with a letter
> in the Debian archive rather than saying "should not" about
> something that's syntactical.

ACK

> My inclination is to second this, but I want to make sure that we've
> answered your and Julien's objections first.

Thanks!

regards,
-mika-

signature.asc

Bill Allombert

unread,

Apr 4, 2011, 6:40:02 AM4/4/11

to

On Mon, Apr 04, 2011 at 02:23:25AM -0500, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
> > On Sun, 03 Apr 2011, Russ Allbery wrote:
>
> >> My inclination is to second this, but I want to make sure that we've
> >> answered your and Julien's objections first.
> >
> > And for complete reference, dpkg accepts those version in
> > /var/lib/dpkg/status (so that dpkg still works for users with affected
> > packages installed) but will not a accept to install a .deb with a bad
> > version anymore.
>
> One possibility would be to mandate in policy that:
>
> 1. upstream_version must start with a digit;

Unfortunately, we cannot force upstream to use a version that start by a digit,
We would need to document a mangling process for upstream version that start
by a letter.

I really fail to see the motivation for this change in dpkg.

So far, I am objecting to the change as it is.

Cheers,
--
Bill. <ball...@debian.org>

Imagine a large red swirl here.

signature.asc

Carsten Hey

unread,

Apr 4, 2011, 7:10:01 AM4/4/11

to

* Bill Allombert [2011-04-04 12:03 +0200]:

> Unfortunately, we cannot force upstream to use a version that start by a digit,
> We would need to document a mangling process for upstream version that start
> by a letter.

upstream_version git1234 could be prefixed with epoch 0 and thus lead to
the version number 0:git1234-debian_revision. Maybe this could be
mentioned in the policy.

Regards
Carsten

Raphael Hertzog

unread,

Apr 4, 2011, 8:20:02 AM4/4/11

to

Hi,

On Mon, 04 Apr 2011, Bill Allombert wrote:
> > 1. upstream_version must start with a digit;
>
> Unfortunately, we cannot force upstream to use a version that start by a digit,
> We would need to document a mangling process for upstream version that start
> by a letter.

We have no upstream with such versions currently in Debian. I don't really
see the point of your objection. There's no supplementary work involved in
Debian.

I doubt we'll ever have to mangle the version name to satisfy the
constraint but even if we have to, it's trivial to add a leading 0.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--

Raphael Hertzog

unread,

Apr 4, 2011, 8:40:02 AM4/4/11

to

On Mon, 04 Apr 2011, Carsten Hey wrote:
> upstream_version git1234 could be prefixed with epoch 0 and thus lead to
> the version number 0:git1234-debian_revision. Maybe this could be
> mentioned in the policy.

No, the check is on the first digit of the "upstream version". The epoch
is ignored.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--

unread,

Apr 4, 2011, 4:10:01 PM4/4/11

to

Jonathan Nieder <jrni...@gmail.com> writes:

> What about previously-in-archive packages?

Are there any of significance? The example you gave in your previous mail
doesn't appear in the BTS at all, so I assume it's quite old if it was
ever in the archive.

Raphael said that dpkg wouldn't break already-installed packages. Policy
primarily applies to packages going forward, plus to references to those
packages in versioned dependencies and the like.

> And what about higher-level packaging tools --- what document describes
> their contract with dpkg[1]?

I don't know that we have one at the moment; regardless, it's not Policy.

> It is relevant to policy because the proposed change in policy and its
> implementation would have fallout. It is worth considering whether
> policy can do something to mitigate that, or at least whether there is
> _some_ avenue in the Debian project to prevent this damage.

Your primary concern is having existing packages stop working because
tools drop support for version numbers that they currently support? Would
adding a non-normative footnote to that effect help? Something like:

In previous versions of Policy, upstream version numbers beginning
with alphabetic characters were allowed but discouraged (a "should
not" instead of a "must not"). There may, therefore, be older Debian
packages with upstream versions starting with an alphabetic character.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

--

Jonathan Nieder

unread,

Apr 4, 2011, 4:40:02 PM4/4/11

to

Russ Allbery wrote:
> Jonathan Nieder <jrni...@gmail.com> writes:

>> What about previously-in-archive packages?
>
> Are there any of significance?

I don't know. The example I gave was from a dpkg bug report, and I
don't know if it was contrived or not (one would have to ask the
submitter).

I admit that the principle that dpkg can introduce and is introducing
many parsing regressions with policy as its justification is more
important to me than this particular example. A reasonable
justification for the policy _and_ dpkg change would be "allowing this
is too much trouble, and almost no packages took advantage of it, so
let's disallow it and simplify life for everyone". So please don't
take my comments here as a strong objection.

> ... if it was ever in the archive.

One can check at snapshot.debian.org.

>> And what about higher-level packaging tools --- what document describes
>> their contract with dpkg[1]?
>
> I don't know that we have one at the moment; regardless, it's not Policy.

In practice, Policy is being used that way. I agree that that is not
really a good thing.

>> It is relevant to policy because the proposed change in policy and its
>> implementation would have fallout. It is worth considering whether
>> policy can do something to mitigate that, or at least whether there is
>> _some_ avenue in the Debian project to prevent this damage.
>
> Your primary concern is having existing packages stop working because
> tools drop support for version numbers that they currently support? Would
> adding a non-normative footnote to that effect help? Something like:
>
> In previous versions of Policy, upstream version numbers beginning
> with alphabetic characters were allowed but discouraged (a "should
> not" instead of a "must not"). There may, therefore, be older Debian
> packages with upstream versions starting with an alphabetic character.

Personally, my primary concern is (as mentioned before) that dpkg still
be usable for testing old packages.

If Policy is not where the packaging system is documented, I don't
think a footnote is needed or would be helpful. What would be useful
is a consensus that (for example) various tools working with version
numbers should accept versions starting with an alphabetic character.
An alternative would be a consensus that tools working with version
numbers should still behave reasonably [for some definition of
reasonable] when given an invalid one, so dpkg could be permissive as
it pleases. Otherwise, the situation is kind of unfortunate.

Jonathan Nieder

unread,

Apr 4, 2011, 4:50:01 PM4/4/11

to

Russ Allbery wrote:
> Jonathan Nieder <jrni...@gmail.com> writes:

>> What about previously-in-archive packages?
>
> Are there any of significance?

Ah, I forgot to say: I think changing this to a "must" with advice to
add a 0 when the upstream version does not start with a number would
be a good change. Based on your clarifications, I don't think there's
anything left to do after that. Packaging system policy for ancient
and otherwise noncompliant packages can be left to the packaging
system maintainers.

Sorry for the confusion.

gregor herrmann

unread,

Apr 4, 2011, 7:20:01 PM4/4/11

to

On Mon, 04 Apr 2011 12:40:01 -0700, Russ Allbery wrote:

> I think this is an interesting conversation, but so far as I can tell it's
> not particularly relevant to Policy. There are no such packages with
> those version numbers currently in Debian, so Policy can simply say that
> there will never be in the future either and be done with it.

There is (or better: was) cnews, in etch and lenny, with
cr.g7-40.{1,4}.

I noticed this because of
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 699262 package 'cnews':
error in Version string 'cr.g7-40.4': version number does not start with digit
each time I build a package (maybe I should just remove oldstable
from my sources.list at some point :))

(Just as a side note, and not relevant for policy.)

Cheers,
gregor

--
.''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
`- NP: Tom Waits: Innocent When You Dream

signature.asc

Bill Allombert

unread,

Apr 5, 2011, 4:10:02 AM4/5/11

to

I formally object to that change in policy, since no rationale is provided.
For the time being, #620566 is a bug in dpkg.

signature.asc

Thorsten Glaser

unread,

Apr 8, 2011, 9:20:02 AM4/8/11

to

On Mon, 4 Apr 2011, Carsten Hey wrote:

> upstream_version git1234 could be prefixed with epoch 0 and thus lead to
> the version number 0:git1234-debian_revision. Maybe this could be

Nah. Just drop the leading 'git'.

On Mon, 4 Apr 2011, Raphael Hertzog wrote:

> We have no upstream with such versions currently in Debian. I don't really

We have, mksh version numbers are mangled (see its watch file)
in a defined way. It uses a repacked source as .orig.tar.gz,
but since dpkg’s extraction mechanism doesn’t really care, for
a package with a normal tar.gz upstream this wouldn’t even matter.

bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec) ‣‣‣ Please let MySQL and MariaDB finally die!

Goswin von Brederlow

unread,

Apr 8, 2011, 2:00:01 PM4/8/11

to

Raphael Hertzog <her...@debian.org> writes:

> On Sun, 03 Apr 2011, Russ Allbery wrote:
>> My inclination is to second this, but I want to make sure that we've
>> answered your and Julien's objections first.
>
> And for complete reference, dpkg accepts those version in
> /var/lib/dpkg/status (so that dpkg still works for users with affected
> packages installed) but will not a accept to install a .deb with a bad
> version anymore.
>
> Cheers,

It does not allow them in available though breaking many systems that
have or in the past had a package with such a version available. At
least 4 people on irc have run into that problem that I saw already.

MfG
Goswin

Raphael Hertzog

unread,

Apr 8, 2011, 2:40:01 PM4/8/11

to

On Fri, 08 Apr 2011, Goswin von Brederlow wrote:
> It does not allow them in available though breaking many systems that
> have or in the past had a package with such a version available. At
> least 4 people on irc have run into that problem that I saw already.

It does allow them in available. Those people are confused
or affected by something else.

They might not know how to get rid of the warnings though (dpkg
--clear-avail).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--

chris h

unread,

May 22, 2011, 6:00:02 PM5/22/11

to

On Tue, Apr 5, 2011 at 10:06 AM, Bill Allombert
<Bill.Al...@math.u-bordeaux1.fr> wrote:
> I formally object to that change in policy, since no rationale is provided.
> For the time being, #620566 is a bug in dpkg.

So, should this bug then be assigned back to dpkg?
Is there anything which prevents fixing this bug?

Thanks,
-ch

Bill Allombert

unread,

May 24, 2011, 3:50:02 PM5/24/11

to

Hello,

I am reassigning this bug to dpkg for the following reason:

1) No rationale are provided for the change.

2) This change breaks actual packages. Even if no such package exist in squeeze, users
could still want to install older or unofficial packages, or created with dpkg-repack.

3) As a matter of policy, we should not encourage developpers to upload packages that
conflict with Debian policy and then ask for a policy change to match before a consensus
for the change is established, since this creates an unwanted pressure on the policy
process by breaking the status quo principle.

4) No consensus exist on the policy change.

5) Even this policy change was accepted, it would still be a bug in dpkg to reject
packages that were made before this policy was implemented.

Cheers,
--
Bill. <ball...@debian.org>

Imagine a large red swirl here.

--

Raphael Hertzog

unread,

May 24, 2011, 5:20:02 PM5/24/11

to

Hi,

On Tue, 24 May 2011, Bill Allombert wrote:
> 2) This change breaks actual packages. Even if no such package exist in squeeze, users
> could still want to install older or unofficial packages, or created with dpkg-repack.

The next version of dpkg has --force-bad-version to work around this.

I'm not sure it's highly constructive to ask Guillem to revert the change
at this point since the impact on Debian is very low and a way has been
provided to install packages with bad versions.

Please reconsider. I think it's been well explained that version numbers
ought to start with a "number".

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--

Joey Hess

unread,

May 27, 2011, 6:00:02 PM5/27/11

to

Raphael Hertzog wrote:
> Please reconsider. I think it's been well explained that version numbers
> ought to start with a "number".

Where? Also, f is a number around here.

Example breakage includes the bitlbee bzr snapshots, which many stable
users of bitlbee were probably using.

--
see shy jo

signature.asc

chris h

unread,

Jun 16, 2011, 5:10:02 AM6/16/11

to

Has there been any progress on this bug?
We (Grml) would like to switch back to short Version: strings for our
kernel packages, as they already have the major "version number" in
the package name, to allow co-installation of multiple versions, and
there's no point in duplicating this info in the Version field.
(Making the Version field relatively long and unreadable.)

Raphael Hertzog

unread,

Jun 16, 2011, 5:30:03 AM6/16/11

to

Hi,

On Thu, 16 Jun 2011, chris h wrote:
> We (Grml) would like to switch back to short Version: strings for our
> kernel packages, as they already have the major "version number" in
> the package name, to allow co-installation of multiple versions, and
> there's no point in duplicating this info in the Version field.
> (Making the Version field relatively long and unreadable.)

"0" is very short. If you don't need the version at all, you don't need to
put a text string either.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--