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

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



On Tue, 25 Mar 1997, Christian Schwarz wrote:
> Wouldn't it be better to change the few packages that use epochs so that
> the old version of dpkg can handle it? IMHO most users would prefer it if
> dpkg won't upgrade a single package (because its version number is
> conseridered less than the installed one) instead of having to go through
> this pain. (It's not much pain unless you know how to do it :-)

First, the technical issue:

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.

Specifically, any package using epochs should include the following in
the preinst script:

dpkg --assert-working-epoch 2>&- || {
    echo -e "\nYou must upgrade dpkg before installing this package.\n"
    false
}

If they don't, it's a bug for that package, and should be reported as
such.  Please, someone with more time than I do so---I'm working hard
on the axp port (as well as that pesky job they pay me for), so I
don't have time to do this.

Second, the philosophical issue:

While epochs seem to be an unnecessary, broken thing to people who use
dpkg, epochs are a necessary ingredient to insuring that dselect works
correctly in the face of upstream maintainer perversity or debian
maintainer mistakes.

Specifically, epochs are a way for a maintainer to tell dselect that
although the version number of this package makes it look like this
package is older than the one installed, it's really not.

If we remove them, then every time an upstream maintainer makes a
non-intuitive change to a version number, or a debian maintainer makes
a dumb choice like I did in numbering zlib initially, we will have to
somehow let people know that they now have to upgrade the package by
hand with dpkg, rather than being able to give dselect the information
it needs to DTRT automatically.

I know a lot of people here may not use dselect, but I think a lot of
users do, I and don't think we want to make things harder than
necessary (though I'll admit that the current problems aren't exactly
making things easy).

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
version of dpkg with which it was built, as well as a list of features
used.  Upon installation, the user's dpkg could then verify that that
all those features are present, and we could use dpkg numbering to
represent major interface changes.  Then we would put the
responsibility for making sure packages are compatible upon dpkg
rather than the maintainer.

Until then, though...

Mike.


Reply to: