Re: SOLVED: Re: Bug#8294: dpkg: Packages with epochs make old Debian installations not upgradable
Michael Alan Dorman <firstname.lastname@example.org> writes:
> This problem has already been solved by Guy, and the solution has been
> posted to the list, and I believe put in the current policy/programmer
Not quite. This prevents an older version from attempting to install
a package using epochs, but old versions of dselect are so broken that
they will die if they see an epoched version in the available file.
Downward incompatibilities in the Packages file aren't allowed so
there's really no way to fix this.
(There actually is a way to fix it - by putting the epoch in a
seperate field in the control file instead of attached to the version.
The pre-epoch dpkg and dselect will both ignore unknown fields, but
they will balk at upgrading one of these hypothetical "Epoch:" using
packages. I don't know how hard it would be to implement something
like this, but I don't think it's worth it.)
> One thing we might consider doing, upon a Great Dpkg Rewrite, would be
> to have dpkg record in the control information of each package the
It already supports this. From deb(5):
The first member is named debian-binary and contains a
series of lines, separated by newlines. Currently only
one line is present, the format version number, which is
currently 2.0. Programs which read new-format archives
should be prepared for the minor number to be increased
and new lines to be present, and should ignore these if
this is the case.
If the major number has changed an incompatible change has
been made and the program should stop; if it has not then
the program can safely continue, unless it encounters an
unexpected member in the archive (except at the end), as