Re: Idea for the burner
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
be a bit better before I call it a great and easy tool. There were a
couple of times that dselect purged things I didn't want to, because I
didn't go through the whole list and checked everything, etc.
I think dselect needs to be layed out better, but to tell you the truth, I
have no idea how to represent that amount of information in an easy to
read format. The current system is workable, but I don't believe it
necessarily is ideal. This is probably due to the side effect of having a
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...
> 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
pretty self explanatory and includes a lot of help screens (too many, in
fact. I'd like a way to have it NOT display help screens since I know my
way around it pretty well...). However, I agree, it should have a complete
man page if it doesn't already. This is just "professional."
> of what is going on in dselect and I got used to dpkg. So, apart from the
> first time at installation, I never use dselect anymore. I guess that was
> not the intention of dselect's developers. Why isn't there a
> dselect-HOWTO? (Maybe I should try writing that then instead of this :-)
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.
However, one can argue that dselect is for initial installations, and the
dpkg utilities under dselect are for everyday usage, which works out quite
nicely in general...
>
> Like, a couple of days ago I just read about the menu package on this
> list. I bet I am not the only one who didn't have a clue about even the
> existance of it. Yet, from what I've read it 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. There should perhaps be a Debian
Tips and Hints FAQ/HOWTOW/book/whatever that collects little bits of
useful info that don't necessarily correlate with one another.
>
> Also, I think it would be better to drop info (sorry, you die-hards GNUdes
> out there.) Lets have all the info stuff as lynx-enabled HTML, it provides
I believe you can have the best of both possible worlds with convertors.
That way you can have HTML/postscript/texinfo/whatever sources of
essentially the same document. Not everyone will have lynx, and not
everyone will use texinfo, etc.
Reply to: