[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Important information regarding upcoming dpkg 1.16.2 upload



Hi,

On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:
> I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
> this weekend or beginning of next week the latest (after some final
> polishing).

Unfortunately I found some issues with the selection handling and with
dselect and this didn't happen. I'm doing final testing and polishing
now and should be uploading later today, if nothing else comes up...


With multiarch, non-installed selections w/o an architecture, do not
make sense, in addition there's no guarantee they match any entry
from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present. As such the new dpkg will silently drop any
such selections, which look like (with possible Section and Priority
fields):

  Package: foo
  Status: install ok not-installed

Because those should have been already installed if they were
available, I don't think this should cause any issues, but if you
want to preserve them you'll need to save them before upgrading:

  dpkg --get-selection '*' > selections

In addition selections for packages unknown to dpkg will not be
accepted anymore.

> On-disk db damage
> -----------------

> [...], upgrading from those versions to the new dpkg 1.16.2 might
> cause the status db to get messsed up in some conditions. Before
> upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
> make sure there's no package present (i.e. with status >= config-files)
> with a mix of M-A:same and non-M-A:same instances. If there's such package
> with two instances, the new dpkg will consider that a “cross-grade” and
> as such replace one of them with the other, depending on the order they
> are parsed, but leaving any control files untouched; if there's more than
> two instances the new dpkg will outright refuse to parse such bogus and
> inconsistent status db.

I reworked the code to make it more resilient against manual edits of
the status file, which while not a recommended action it might happen
from time to time. As a side effect, this should turn the above issue
into a parsing error, instead of silent lose of information when
upgrading from those dpkg versions.

regards,
guillem


Reply to: