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

Re: SOLVED: Re: Bug#8294: dpkg: Packages with epochs make old Debian installations not upgradable

Michael Alan Dorman <mdorman@calder.med.miami.edu> 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
> manuals.

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
       described below.


Reply to: