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

Re: Intention to re-write /usr/sbin/install-info


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


 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: