(sorry for the bad cc: people, debian-admintool@lists.debian.org doesn't exist, I just found out)
On Thu, 6 Mar 1997, William Chow wrote: > > On Fri, 7 Mar 1997, J.P.D. Kooij wrote: > > > > Like, dselect is a great and easy tool, but there is no manpage for it... > > Dselect is pretty intuitive once you get the hang of it, but it needs to That's like saying: The water's pretty warm when you're swimming in it for a while." Anyway, I believe that for first use dselect is in fact intuitive enough, that is not my point. > LOT of packages in the Debian system. While it may be a headache to run > dselect and go through all those packages, I guess it's better than having > very few packages... No complaints from me about that aspect of dselect either here. It's not really that essential. Besides, my pc is fast enough (could be better thoug - both) Here _is_ my point: dselect is "all or nothing" and has no documentation. > > That is a BUG, people. I have spelled the dpkg manual to get a hunch > I'm not quite sure that dselect doesn't have documentation. The package is Well, I finally found some: "dpkg programmers' manual - chapter 14: dselect's interface to its installation methods". Not a really place I'd look into for some basics on dselect if I were a newbie and not yet fully at ease with all the difficult switches and options in the dpkg manpage. > However, I agree, it should have a complete > man page if it doesn't already. This is just "professional." Manpages (and maybe, ok, info) are for people who have at least some sense of orientation in unix. Dselect should be even more conservative in its estimate of the user. This is a sidetrack however. > I tend to do this too. The thing is that dselect is too unwieldy to use > for small upgrades/installations of specific programs. It's too much of a > pain to configure it to install one package... The problem isn't with a > lack of dselect documentation, IMHO, but due to the way dselect is setup. Right. You have to do some wizzo tricks with dpkg that aren't even told in its manpage before you can use the user friendly front end to dpkg. That's kind of silly. _If_ it has to be like this, why not abolish dselect and give people a fully-scripted standard installation and let them figure it out with dpkg for all the rest. I'm not trying to say that this is what should be, it's just pretty much what I had to do. > > .. Yet, from what I've read it [ menu ] is a wonderful package, > > integrating other packages the way the debian system can do so fine. The > > way a structured documentation should be (and I believe most building blocks > > for something like it are already there.) > Documenting every available package would seem unwieldy. I'm afraid that > this will be more the rule than the exception, when useful packages get > lost in the sea of packages available. One could just say all that as well about the packaging and dependency system. Yet it works. It works very well and quite painless once the framework is up. It is even creating an added value with the all the scripted configuration options that come with the packaging scripts. Or the menuing system. IMHO, if that sort of thing could be done for the documentation, then that would be much more valuable than the nice menu thing. > Tips and Hints FAQ/HOWTOW/book/whatever that collects little bits of > useful info that don't necessarily correlate with one another. And keep it up to date and relevant, _just_like_the_packages_ they should come along with. Like there is a dpkg for the packaging there should be something similar for the documentation (maybe as an integral part of dpkg.) However, the current info program and documentation style clearly doesn't provide or even possibly support this. > essentially the same document. Not everyone will have lynx, and not > everyone will use texinfo, etc. I know what I would put my money on though... (O'Reilly Associates Press shares probably anyway. Who says this linux thing is free unix? These books do cost, man. :-) Cheers, Joost
