On Tue, Aug 03, 1999 at 09:02:53PM -0400, Michael Stone wrote:
> (And thus useless to me.) I don't argue that dpkg has some problems with
> symlinks if a package changes the path by which it references one of its
> files. It does not have problems (as far as I have found) if a package
> consistently uses the same path when referencing the file, whether or
> not that path passes through a symlink. That's the case I'm interested
> in and which I've been testing.
*OH*. No, that's completely correct.
> No, what I wrote works fine. The examples were irrelavent. You
> apparantly ignored the part where I said that all packages should put
> their stuff into /usr/doc without regard for whether it's a symlink or
> anything else.
This means packages will have to use /usr/doc instead of /usr/share/doc
until dpkg is fixed. "until dpkg is fixed" could be forever.
This seems like it might also require pre-dependencies on base-files for
every package (so that they don't accidently create /usr/doc as an
actual directory instead of as a symlink).
Hmmm. This also seems like it might require pre-dependencies from every
package against the new version of dpkg that handles following symlinks
correctly.
> 1. use both /usr/doc and /usr/share/doc; this upsets the partial
> upgrade people, and worries the UI people.
"upsets" and "worries" aren't really very precise. It results in a
"needlessly" inconsistent user interface for accessing documentation
for potato and partial upgrades from <=potato to >potato.
> 2. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of
> preinst/rm scripts; this upsets the anti-bloat people and horrifies
> the elegance people :)
It creates postinst and prerms where there never used to be any, but lets
them go away after woody.
> 3. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of a cron
> job or somesuch; this upsets the partial upgrade people, horrifies
> the elegance people, and terrifies the people who don't want cron
> jobs automatically deleting things on their systems.
It means documentation can be lost when doing a downgrade from a
/usr/share-using package to a prior, /usr/doc-using, version of that
package.
It means dangling symlinks could exist for up to 24 hours (or however
often the job runs). It means symlinks might not exist for the same
amount of time.
> 4. use both /usr/doc and /usr/share/doc but provide symlinks from
> each package in one to each package in the other by means of an
> optional script run manually by the admin; this upsets the partial
> upgrade people, worries the UI people, and horrifies the elegance
> people.
Same problems as the cron job, and not automatic.
> Don't explicitly use /usr/share/doc yet, and we can rig up a symlink
> to effectively use /usr/share/doc until we come up with a better
> solution; this upsets the policy-says-I-can-therefor-I-must people
> and dismays the people who have already converted their packages
Requires changes to dpkg, which don't have a particular history of being
made. Possibly requires lots of pre-dependencies that will last for ever.
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.
``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
Attachment:
pgpD13GUVXBaw.pgp
Description: PGP signature