Re: Bug#51116: Suggestion: Packages should carry a manpage
(I fondly remember my second slackware install. I had found out enough the
first time around to know that the names of commands was key to learning
linux. Several of the core slackware packages listed all the commands in
them in their descriptions, and raced against the install to get the command
names in each package written down before it moved on to install the next.
But then I found out about ls /usr/bin, and threw my notes away ...)
Chris Waters wrote:
> > Yuck. Package descriptions shouldn't become dumping grounds for
> > every peice of information about a package. The sole purpose of a
> > package description is to let you decide if you should
> > install/remove a package.
I'm happy to discover the packaging manual backs me up on my idea of what
the package description is for:
The description is intended to describe the program to a user who
has never met it before so that they know whether they want to
install it.
Though it adds:
It should also give information about the significant dependencies
and conflicts between this package and others, so that the user
knows why these dependencies and conflicts have been declared.
> Hmm, compelling argument --I think I basically agree. However, there
> are already a large number of packages (util-linux, shellutils,
> findutils, etc.) which already do this, which is why I suggested it.
Yes and no. I maintain a package that does this too (bsdgames). One
difference is that bsdgames, util-linux, shellutils, and findutils are
collections of a bunch of unrelated commands, which can't all be described
in detail in a package description.
The naive user will install util-linux, shellutils, and findutils
automatically since they are in base and are priority required. They will
decide to install bsdgames or not based on the first part of its
description.
The advanced user will choose whether to install bsdgames based on if they
feel like having the pom utility available, or playing a game of robots or
adventure. Thus listing all the games here makes sense. And they will look
at the commands listed in the descriptions of the other three packages and
quickly realize that removing them would be crippling.
Notice that at least some of the commands in these 4 packages are well known
to advanced users. We all know what adventure, xargs, test, and fdisk are,
and thus we can use the names of those binaries in a package description to
help us make an informed decision. We do *not* know what "antlr" is, and so
putting it in the description of pccts does not help us at all. It helps
naive users even less.
> Personally, I'd rather just leave this whole proposal out. But I
> think that putting something in the package description is a lesser
> evil than creating a man page for a package. I prefer to have the
> package system isolated from and unentangled with the actual operating
> system itself. A man page for a package seems like a violation of
> boundaries to me. It just feels wrong.
I think this whole proposal is misguided. If people don't know about 'dpkg -S',
educate them, explain things in README.Debian, there are planty of machanisms
for conveying this information and there is no reason to think a man page or
a package description is better then the mechanisms we already use.
--
see shy jo
Reply to: