Re: Intention to re-write /usr/sbin/install-info
Hi,
Jeez, this is like deja vu all over again.
>>"Brandon" == Brandon Mitchell <bhmit1@mail.wm.edu> writes:
Brandon> Yes they do two different things. That's why we have to pick
Brandon> one or the other instead of having just one that does both
Brandon> (although if someone could find a way to do both, and accept
Brandon> both flags, that would be most appreciated).
No, that is continuing the confusion. We should write a
dinstall-info, and let install-info remain GNU. We should phase out
Debian install-info, maintaining an upgrade path for the users.
Brandon> That's dinstall-info right? We would create it, but we need
Brandon> to have some backward compatability. This involves:
Brandon> That's dinstall-info right? We would create it, but we need
Brandon> to have some backward compatability. This involves:
Brandon> 1) some kind of merge of ours and the gnu versions (yet to see it),
No, no. We do *not* want to merge the programs, since Debian
does not *need* what GNU install-info does _at all_.
Brandon> 2) a way to phase out old 1.3 packages (yet to see a really good one),
Please critique my posting on this subject, I'm reposting my
solution below. Are there any technical flaws in it?
Brandon> 3) a changing path solution (and a bad one at that)
I agree.
Brandon> 4) a script (which I've done, but I don't consider it a
Brandon> perfect solution),
I also think this solution is suboptimal.
Brandon> 5) ignore it (considering how small the problem is, I don't mind this),
I mind this.
Brandon> 6) or some other way (can't think of any others).
Brandon> Am I missing something?
Yes, my previous post, and Ian Jacksons about the structuring
of the new Debian method of handling updates to info directries.
I have already proposed a means of phasing out the use of
install-info in Debian in favour of a rewritten dinstall-info, making
sure that the prerm is handled correctly. There were no objections to
this the last time it appeared, so I hoped we had a solution. Since
apparently public memory is short, I'll re post it here. Please point
out any flaws that you see here.
Also, Ian Jackson proposed (rightly so, IMHO) that the method
we use should not involve packages calling a program which edits a
file in place (prone to corruption), but like menu, each package
installs a file in a well known directory, and the program can
recreate the info dir file at any time from this dorectory.
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.
The conflicts with packages using install-info are not
practical. The above method shall handle it.
manoj
--
Make money, not war. slogan popular in libertarian circles in the
early 70s
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: