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.
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.
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
E: Sub-process /usr/bin/dpkg returned an error code (2)
A package failed to install. Trying to recover:
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.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 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
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.
>
> 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.
>
> 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
Thanks for a very clear report!
> 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.
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.
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");
}
--
On Fri, 30 Jul 2010, Guillem Jover wrote:
> 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.
Would it be doable to add a pre-inst snippet that sed/awks the
available/status file? Or is that not going to work because dpkg has
already loaded the file and won't take into account those changes? I guess
so.
Ideal would be to fix it by replacing invalid characters by
"+invalid+char+removed+by+dpkg+".
sed -i -e '/^Version:/ s/[^-a-zA-Z0-9:.+~ ]/+invalid+char+removed+by+dpkg+/g' /var/lib/dpkg/available
Alternatively it should abort the upgrade and ask the user to cleanup
before-hand. It could give out the requireds commands.
We could also fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397121
so that the cruft in the available file really affects only dselect users.
This would make dpkg more robust in general BTW.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
On Fri, 2010-07-30 at 05:40:39 +0200, Guillem Jover wrote:
> On Thu, 2010-07-29 at 19:58:24 -0500, Jonathan Nieder wrote:
> > Joe Neal wrote:
> > > 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.
Given the amount of comments to these bug reports and their nature I
don't think this would be acceptable, even more given the tedious
recovery needed.
> > 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've been thinking about a proper solution for this, this is what I
think would be ideal, for which I've started coding:
* dpkg should not error out (warn at most, but that might be too
annoying too) when parsing the status and available files, we
might switch these to errors after one Debian release, but maybe
then only for the status file.
* dpkg should error out on parsing bogus versions on anything else,
which include things such as Dpkg perl modules, dpkg-deb,
dpkg --compare-versions, and parsing control files from newly
installed packages, which would prevent installing new bogus packages.
* The version checks will be able to get stricter, there's still some
invalid syntax not being checked for, I've also some preliminary
patches for this.
thanks,
guillem