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