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

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


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

 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: