Re: Intention to re-write /usr/sbin/install-info
First, my appologies to the developers for contining this thread.
On 9 Sep 1997, Manoj Srivastava wrote:
> Hi,
> >>"Brandon" == Brandon Mitchell <bhmit1@mail.wm.edu> writes:
>
> Brandon> On 9 Sep 1997, Ben Pfaff wrote:
> Ben> As a side note in this discussion, are the interfaces of the two
> Ben> install-info programs reconcilable; i.e., could one write a
> Ben> front-end script that detects which install-info program (GNU or
> Ben> Debian) is needed, and then call either ginstall-info or
> Ben> dinstall-info, depending?
>
> Umm, since they do two quite different things, maybe we should
> not be doing this anyway?
Yes they do two different things. That's why we have to pick one or the
other instead of having just one that does both (although if someone
could find a way to do both, and accept both flags, that would be most
appreciated).
> Ben> If this can be done, then it would be a Good Thing to write,
> Ben> IMHO.
>
> Brandon> I wrote a script for this, but no one seemed to care for it.
> Brandon> I thought it was a good thing too, needing only a simple
> Brandon> switch/case statement. Maybe everyone was getting it
> Brandon> confused with the first script I wrote which was a bad thing.
> Brandon> If anyone has the gnu install-info options (i.e. the top of
> Brandon> the man page), send it to me and I'll repost the script for
> Brandon> comment.
I'm still waiting for that man page, would there be one online?
> Oh, I liked the script, I just think we should not be writing
> it in the first place. We have two programs that do two very
> different though related, tasks, and we should not be adding to the
> confusion by keeping the same names here.
The names would change, i.e. dinstall-info, and if you want,
ginstall-info. We shouldn't be writing this script either, but I can't go
back and change the damage that's already been done.
> If someone createes a dinstall-info package, modelled after
> the current menu package, that creates and recreates the info/dir
> file based on snippets included by packages, then we can have all
> packages that put stuff into the dir file adhere to the new standard
> by 2.0 release.
Does this handle the prerm script problem. Someone who removes a debian
package from 1.3 or earlier needs install-info to act like the debian one.
> The script, no matter how brilliant, is the wrong
> approach. Time to stop hiding the dust under the carpet, grasp the
> nettles firmly, and create dupdate-info.
That's dinstall-info right? We would create it, but we need to have some
backward compatability. This involves:
1) some kind of merge of ours and the gnu versions (yet to see it),
2) a way to phase out old 1.3 packages (yet to see a really good one),
3) a changing path solution (and a bad one at that)
4) a script (which I've done, but I don't consider it a perfect solution),
5) ignore it (considering how small the problem is, I don't mind this),
6) or some other way (can't think of any others).
Am I missing something?
Brandon
-----
Brandon Mitchell E-mail: bhmit1@mail.wm.edu
Homepage: http://www.geocities.com/SiliconValley/7877/home.html
PGP: finger -l bhmit1@cs.wm.edu
"We all know Linux is great...it does infinite loops in 5 seconds."
--Linus Torvalds
--
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: