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

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

On 2 Sep 1997, Manoj Srivastava wrote:

> 	Firstly, I would like to ask people to keep their cool on this
>  list; we are supposed to be having a technical discussion
>  here. Secondly, nobody is saying to hell with GNU software (Debian
>  thinks it is GNU/Linux, remember?)

My appoligies if I overreacted a bit.  I get annoyed after repeating 
something the 50th time.  It's nothing you did.  I just happened to be 
replying to your message at that time.

> 	I would prefer the following slower deployment scheme::
>  a) dinstall-info should added immediately, with /usr/sbin/install-info
>    symlinked to it.
>  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. 
>  c) GNU install-info, when it is packaged, should conflict with the
>     current dpkg; it should also confict with some other packages (<=
>     <fixed version). which use the old install-info.
>  d) GNU install-info, when it is packaged, should pre-depend on a a
>     dpkg which does *NOT* also provide the symlink
>  e) GNU install-info should not be provided until the release after
>     dinstall-info is formalized.
> 	In other words:
>   2.0     install-info symlink exists. All packages in 2.0 use
>           dinstall-info. GNU version not yet provided in main
>           distribution. A README file exists so that people who wish
>           can install GNU install-info from experimental (depends on
>           dinstall-info to make sure people do not totally break the
>           system). This experimental package should wipe the
>           symlink. Upgrades from previous versons go smoothly.
>   2.1/3.0 GNU install-info moves into main distribution. Predepends
>             on dpkg (version with dinstallinfo, but no
>             symlink). Anyone upgrading from 1.3.1 and older versions
>             will be told to upgrade dpkg first, and hold off on GNU
>             install-info  until after other packages have been
>             upgraded. 

How are you proposing to solve the prerm problem?  On my system it's more 
than a few packages (grep install-info /var/lib/dpkg/info/*.prerm).  You 
mentioned something about a dpkg upgrade?  What will that do?

> 	This is a slower deployment, but I think it retains an upgrade
>  path, and should move us towards having a true GNU install-info on
>  Debian. 

Considering the recent info I've heard on gnu's stand, maybe they are 
also willing to make some changes as well.

> >> So, to make things a trigle easier for a minority of the people, we
> >> are risking destabilizing the distribution?
> Brandon> Please point out where things are getting less stable.
> 	Any time I have two programs with the same name on my system,
>  when the behaviour depends on how the author happened to set PATH
>  variables, or worse, how the user has set them, then I think the
>  system is quite unpredictable. Pardon me for labelling it unstable. 

No, here we are in agreement.  People kept saying that the changes I was 
proposing would make things less stable.  I'm agreeing that when the path 
effects what program is run it is less stable.  My attempt is to make it 
more stable.  The script solution is not the perfect one, but I'm not 
sure your solution fixes it.  I guess we could make a package with 
several hundred conflicts, it just doesn't seem like the best solution.


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: