severity 590885 important thanks On Thu, 2010-07-29 at 19:58:24 -0500, Jonathan Nieder wrote: > forcemerge 590896 590885
Well, the severity is not critical for sure. More so in this case given that the problem is with the bogus version, and no official package contains one. For reference, the definition for important: “a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.” > Joe Neal wrote: > > I'm aware of the fact that running the Lenny version of Oracle's VB > > package under sid is not supported. > > > > Hell, I'm supprised it even works. It seems starting with 3.2.0 virtualbox has now correct version numbers, and the version for Lenny from <http://www.virtualbox.org/wiki/Linux_Downloads> should work fine. > > Upgrading dpkg fails due to having it installed, however. I'm > > concerned about the potential for Lenny --> Squeeze upgrade > > failures for people with this package installed under Lenny. I guess an option could be mentioning the possible issues with bogus versions on the release notes. > > Here is the error: > > > > Preparing to replace dpkg 1.15.7.2 (using > > .../archives/dpkg_1.15.8_amd64.deb) ... > > Unpacking replacement dpkg ... > > Processing triggers for man-db ... > > dpkg: parse error, in file '/var/lib/dpkg/available' near line 60680 > > package 'virtualbox-3.0': > > error in Version string `3.0.12-54655_Debian_lenny': invalid character in > > revision number > > Actualy, I now seem to be unable to remove the virtualbox package to > > remedy the problem as I initialy planned, leaving my system > > unupgradable. This is going to be fun. > > You can edit /var/lib/dpkg/available by hand, but it might be easier > to try something like this patch. Yeah, editing the available and status files should be the fastest workaround. > As for a proper solution: I have no idea. I am not sure dpkg should > be enforcing policy like this. It might be better to check sanity > by excluding empty strings and some *forbidden* characters and > leaving the rest to checkers like lintian. I was a bit hesitant too when introducing those checks in dpkg, for the same reason. But then considered this, the version syntax is something the Debian (and derived) ecosystem relies on, with parsers, tools, etc, needing a common definition of it, so it's a matter of interoperability, and in this case dpkg is not checking how a package uses date style version or similar, just its syntax. In the same way it checks for the package name syntax for example. Checking for forbidden characters instead of allowed ones is going to be prone to error. And finally, dpkg-dev has been doing stricter version checks for some time now too. > diff --git a/lib/dpkg/parsehelp.c b/lib/dpkg/parsehelp.c > index 5d80213..ed3aba8 100644 > --- a/lib/dpkg/parsehelp.c > +++ b/lib/dpkg/parsehelp.c > @@ -253,7 +253,7 @@ const char *parseversion(struct versionrevision > *rversion, const char *string) { > return _("invalid character in version number"); > } > for (ptr = rversion->revision; *ptr; ptr++) { > - if (!cisdigit(*ptr) && !cisalpha(*ptr) && strchr(".-+~", *ptr) == NULL) > + if (!cisdigit(*ptr) && !cisalpha(*ptr) && strchr(".-+~_", *ptr) == NULL) > return _("invalid character in revision number"); > } I'll consider whether to do something about these bug reports for tomorrow's upload, mostly because this is a regression from the point of view of the user, that had a working dpkg before the upgrade and it suddenly stopped working. But I'm tending to think about this as wontfix. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
