On Fri, Jul 30, 1999 at 04:03:46PM -0700, Chris Waters wrote:
> So, first the lesser of my two current ideas:
> > Chris> docdir() {
> > Chris> dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
> > Chris> cddoc() {
> > Chris> cd $(docdir $1)
> > Firstly, this has to be in every users environemnt
> So we make it a script. Problem solved.
It doesn't just have to be in every user's environment, it has to be (or
at least, ought to be) easily available for arbitrary scripts/programs
to be able to access documentation. It thus needs to work conveniently
with csh, rc, perl, python and C.
It also adds another learning curve to Debian for, what appears to me
to be, very little benefit. Instead of just cd'ing to /usr/src/linux
and running make, we're meant to use kernel-package. Well, that's fine
--- kernel-package makes it a lot easier to deal with upgrading from
one kernel version to another keeping modules in sync and not leaving
cruft lying about on your disk. Instead of just cd'ing to /usr/doc and
poking around with your favourite utilities, you now have to either know
the name of the program in advance and use some special functions which
you've likely never heard of before.
> > Chris> Now we're back to a single probe. We're just probing the
> > Chris> database, not the filesystem.
> > Still does not answer less /usr/doc/<package>[TAB]
> Very true. There are always tradeoffs -- in this case, we gain
> flexibility.
To what end? Is /usr/local/doc particularly common anyway? We certainly
don't have any intention of keeping /usr/doc around, so having more than
one doc directory doesn't seem to help us.
Needless flexibility breeds bugs.
> In any case, this was just ONE proposal. Not necessarily the best,
> but not necessarily the worst. This is *NOT* the proposal I would
> currently support, but it's an idea I wouldn't *completely* reject
> either, if others liked it. I'm just throwing out ideas here, to try
> to open up the debate.
...but on the other hand you would completely reject symlinks even if
others like it. Weird.
> In point of fact, I don't think the symlink proposal is without
> merit either. I just think it's badly timed, and not *necessarily*
> the best proposal.
The symlink proposal is far from perfect --- adding postinst's and prerm's
to every package with the same half dozen lines of code is really pretty
lame. The *proper*, forward thinking solution would be to add a feature
to dpkg to run specific items of code before and after each dpkg run.
But modifying dpkg is infeasible, and we've agreed to, among other things,
keep the needs of our users at the forefront of our minds. And from a
user's perspective, something that keeps the system tidy in the normal
case, and works *now*, is much better than idealistic fantasies like a
working dpkg.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``There's nothing worse than people with a clue.
They're always disagreeing with you.''
-- Andrew Over
Attachment:
pgpM9p7LorC03.pgp
Description: PGP signature