Hi,
Now that dpkg in experimental no longer depends on lzma, I would like
to update lzma to use update-alternatives.
I think the new lzma would have to Pre-Depends: dpkg (>= 1.15.6), so
given policy §3.5 and my unfamiliarity with the workings of apt, this
requires feedback from debian-devel. I thought I should hear your
thoughts first.
Please excuse the long message: this is sort of a draft for a message
to debian-devel, too. Feedback (especially ideas for shortening it)
very much welcome.
Current situation
-----------------
The XZ utils are developed by the same person that put together LZMA
utils. The library at its core has been basically redesigned to be
easier to maintain and use (not to mention supporting another file
format). Development of the old LZMA utils has basically ceased.
Run through appropriate symlinks, the XZ utils can provide the
traditional lzma, unlzma, etc commands with the same supported options.
In the long run, I think these are the right versions of those commands
to provide. For compressing and decompressing LZMA files, they simply
work better (for example, it is harder to exhaust available memory).
Still, I am not personally interested in removing the current lzma
package from Debian for squeeze: maybe this is too conservative, but I
do not want to break some use case I didn’t know about.
Until dpkg 1.15.6, lzma was a pseudo-essential package. Using
alternatives to decide which package provides lzma would be difficult,
because there would be a window of time between when a new version of
lzma not providing /usr/bin/lzma is unpacked and when it is configured
and alternatives set up.
The xz-utils package currently has instructions for providing
appropriate symlinks in ~/bin in /usr/share/doc/xz-utils/README.Debian.
Options
-------
Now that dpkg 1.15.6 can run without /usr/bin/lzma, I can see two
options:
a. Start using update-alternatives in lzma, with
Pre-Depends: dpkg (>= 1.15.6), and introduce a new xz-lzma
package that conflicts with older lzma.
b. Introduce a new xz-lzma package with
Provides/Conflicts/Replaces: lzma.
c. Forgot about xz-lzma, and just let the administrator set things
up herself as she would now.
The obvious advantage of option (a) is that it would make xz-lzma and
lzma co-installable. More importantly, it is just saner: it does not
impose any strange unpacking ordering requirements and it would
obviously do the right thing in even the strangest partial upgrade
scenarios.
The pre-dependency could of course be removed after squeeze.
The main downside is that it is not so nice for downgrading: after
upgrading dpkg and lzma, one would have to install xz-lzma to
downgrade dpkg again. There is no way to reinstall the old lzma
again without passing through a broken state.
What do you think?
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
