Re: Intention to re-write /usr/sbin/install-info
Hi,
[This is a long message, but this does seem to be a complex
transition. Please bear with me.]
>>"Brandon" == Brandon Mitchell <bhmit1@mail.wm.edu> writes:
Brandon> How are you proposing to solve the prerm problem? On my
Brandon> system it's more than a few packages (grep install-info
Brandon> /var/lib/dpkg/info/*.prerm). You mentioned something about a
Brandon> dpkg upgrade? What will that do?
dpkg is the package that currently installs install-info;
changing dpkg to change the name and upgrading is the first
step. I'll go over my proposal in more detail, pointing out how the
prerm problem is handled.
a) dpkg should be modified to rename install-info to dinstall-info,
with /usr/sbin/install-info symlinked to it, asap. This shall be
released with a later release of Debian, maybe 2.0 or 1.3 RX.
Since the symlink exists, prerm from 1.3.1 and earlier continue
to work on upgrades. (One may install the symlink in the postinst
of the dpkg package, so that it does not get removed when dpkg is
removed. The symlink is created if /usr/sbin/install-info does
not already exist, which should be the case after upgrading
to the new dpkg).
b) Debian packages should now use dinstall-info. This may be made a
requirement for release of a future Debian release, maybe even
2.0. Work can commence as soon as the new dpkg is installed. If
we are serious about the requirement for release, the release
master shall remove packages from the distribution that fail to
confirm. However, this is a simple change, and non-maintainer
releases are quite possible to avoid that. Also, have the new
prerm handle the failed-upgrade option, this will fix any future
failed upgrades. From the Packaging manula:
======================================================================
6.3 Details of unpack phase of installation or upgrade
The procedure on installation/upgrade/overwrite/disappear (ie, when
running dpkg --unpack, or the unpack stage of dpkg --install) is as
follows. In each case if an error occurs the actions in are general
run backwards - this means that the maintainer scripts are run with
different arguments in reverse order. These are the `error unwind'
calls listed below.
1.
1. If a version the package is already installed, call
% old-prerm upgrade new-version
2. If this gives an error (ie, a non-zero exit status), dpkg
will attempt instead:
% new-prerm failed-upgrade old-version
======================================================================
c) GNU install-info, when it is packaged, should conflict with the
current dpkg version, and hence can't be installed with it. It
should also confict with some other packages (<= <fixed
version). which use the old install-info.
d) GNU install-info should be packaged into experimental initially,
for people who just have to have it. This experimental version
predepends on the new dpkg, so it will not scribble on
install-info. This version shall remove the symlink, and install
real GNU install-info. This experimental version should not be
provided untill 2.0 R1, and should come with warning about
upgrading to vanilla 2.0 at least before installing the
experimental package. So we cater to the minority who need GNU
install-info, and they should understand we are trying to get to
the point of being able to install GNU install-info without
messing up old Debian users. The inconvenience is regretted.
d1) As a further defensive programming method, the inital
releases of GNU install-info can also divert install-info
to /usr/sbin/texinfo/install-info.dpkg; and install the
actual GNU install-info as /usr/sbin/texinfo/install-info.gnu
/usr/sbin/install-info can be a script that calls the
proper install-info. When the release is stable, in, say,
Debian release 4.0, the diversion maybe removed. This step
is not required, really, but defends us against users that
forcibly install the experimental package with older dpkg
version. Like I said, defensive programming.
e) GNU install-info should not be provided in the main distribution
until the release after dinstall-info is formalized. So, in
release 3.0, dpkg shall no longer provide the symlink. Gnu
install-info shall move into the main distribution. Upgrade path
is preserved for upgrades from 2.X RY. Upgrade from 1.3* versions
will work because of the way dpkg works, the new prerms shall
handle things.
Brandon> No, here we are in agreement. People kept saying that the
Brandon> changes I was proposing would make things less stable. I'm
Brandon> agreeing that when the path effects what program is run it is
Brandon> less stable. My attempt is to make it more stable. The
Brandon> script solution is not the perfect one, but I'm not sure your
Brandon> solution fixes it. I guess we could make a package with
Brandon> several hundred conflicts, it just doesn't seem like the best
Brandon> solution.
The conflicts with packages usingf install-info are not
practical. The above method shall handle it.
manoj
wiping his brow
--
Why is this so clumsy? The trick is to use Perl's strengths rather
than its weaknesses. --Larry Wall in <8225@jpl-devvax.JPL.NASA.GOV>
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: