Re: [SCM] dpkg's main repository branch, master, updated. 1.15.8.10-272-g58e7276

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2011-01-31 at 15:48:37 +0100, Raphael Hertzog wrote:
> On Mon, 31 Jan 2011, Guillem Jover wrote:
> > The following commit has been merged in the master branch:
> > commit 58e7276b69be105735eccb3c18c2b28d3a2ec2e5
> [...]
> > +  * Always warn when parsing any package control data which does not have
> > +    an Architecture field.
> 
> This looks like wrong. There are several cases where we have status
> information without the Architecture field.

Wow this commit sucked, should not code while sleep deprived. :(

> After a run of dpkg --set-selections we can have many:
> ┏rivendell:~/deb/core/dpkg (master)
> ┗(720)$ echo "foo install" | sudo dpkg --set-selections
> ┏rivendell:~/deb/core/dpkg (master)
> ┗(722)$ LANG=C sudo dpkg -s foo
> dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 5070 package 'foo':
>  missing architecture
> Package: foo
> Status: install ok not-installed

Pushed now a fix, thanks.

> > -  if (pkg->available.arch && *pkg->available.arch &&
> > -      strcmp(pkg->available.arch, "all") &&
> > +  if (strcmp(pkg->available.arch, "all") &&
> >        strcmp(pkg->available.arch, native_arch))
> >      forcibleerr(fc_architecture,
> >                  _("package architecture (%s) does not match system (%s)"),
> 
> There is a regression here that was not documented in the commit log, hence I
> assumed it was unintended and fixed it in a subsequent commit. Package without
> an architecture field used to install fine, with this change they don't. I added
> a test case as well.

This was actually intended, but as it's a functionality change it should
have been in a separate commit, or at least explicitly documented in the
commit message. :/ The reasoning is (as hinted on the last paragraph of
the 58e7276b commit message) that packages w/o an Architecture field
should still be supported, but that does not imply we have to accept
them by default. So in that sense --force-architecture implies it's
still supported, but not blessed as a conforming package at this point
in time, as this should really only happen with either ancient packages,
or current bogusly built ones.

So if you don't mind I'll be reverting 13637ddf and document this
properly.

thanks,
guillem