On Fri, Jul 30, 1999 at 08:20:18PM -0700, Joseph Carter wrote: > > I'm tempted to object to any such proposal that doesn't have the support > > of Ian Jackson or Klee Dienes or someone equally familiar with dpkg > > internals. > Then provide a better option. I'm beginning to agree with Manoj here. > I'm seeing a lot of "I will object to this" and not many better solutions > offered.
That's probably because every solution to this has problems of one sort
or another. I think the symlinks proposal is the best one so far ---
it addresses the issue correctly, and it's drawbacks are both aesthetic
(crufty symlinks that don't damage the system; and extra postinsts)
and temporal (upgrading to woody+1 gets rid of both the symlinks and
the extra postinsts).
I also think the special-script-that-accesses-both-locations is
better than this because it doesn't have any possibility of causing a
catostrophic failure by damaging the dpkg database. Heck, even the cronjob
proposal is better because where it *may* cause a catastrophic failure at
least it'll be limited to just one package and not possibly all of them.
Messing with dpkg's database is *not* something to be done lightly.
Getting knowledgable comment from the author's seems the *least* thing
that should be done.
And yes, I am annoyed that getting such comment should be as difficult
as it is. It's *still* necessary though.
Let me summarise the proposals so far as I see them: (in order of my
personal preference)
* symlinks managed by postinst/prerm
- requires lots of packages to add postinsts/prerms for potato
and woody, and then to get rid of them for woody+1
- may leave crufty symlinks about on systems where (a) the admin
doesn't fix it (b) hasn't had the base packages upgraded to woody+1
* do nothing special
- means the admin, and all automated tools have to look in both places
or miss documentation
* making a script that works out which of /usr/doc /usr/share/doc to use
- doesn't work for browsing by hand
- needs to be written/accessible from lots of different languages
- is significantly different to any other system on the planet
+ makes it easy to "support" /usr/local/doc or similar ("support"
in scare-quotes because I'm not really sure of the value of
such support in this case. YMMV)
* cronjob that adds/removes symlinks in cron.daily
- downgrading a package that uses /usr/share/doc to a prior version
that uses /usr/doc will cause dpkg to move files from
/usr/share/doc/foo to /usr/share/doc/foo via a symlink, which is
believed to be dangerous. (*)
- may leave dangling symlinks / may not have symlinks for up to 24 hours
* fiddling with the dpkg database
- bugs in the script can cause catastrophic system failure by messing
up the dpkg database (*)
- must be done by the admin by hand, rather than automatically as part
of the upgrade to potato/woody
- script is difficult to get right on common configurations
* add support to dpkg for pre and post processing on a global basis
- requires dpkg modifications (*)
+ allows update-menus and similar programs to be implemented much more
cleanly.
I consider the points marked with a (*) to be completely unacceptable,
because I read both comp.risks and debian-dpkg. Adding functionality that
is difficult to get right, and likely to cause severe breakage if it's
*not* done right is Fundamentally Stupid.
By "completely unacceptable", I mean that it's unacceptable to just say
"we should do this". If you *can* do it (ie, write the program/make the
modifications), and then can show why the original fears were unfounded
(look, iwj even says this is okay!), then, naturally, there's no problem.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgptzaR8Vpu7B.pgp
Description: PGP signature
