On Wed, Aug 04, 1999 at 09:23:17AM +1000, Anthony Towns wrote: > On Tue, Aug 03, 1999 at 05:32:33PM -0400, Michael Stone wrote: > > > > > Possibly I'm just misunderstanding what you're suggesting should be done > > > > > though. Can you give a sequence of commands that does whatever you're > > > > > suggesting, and still has those three packages survive unscathed? > > > > That's simple enough. > > > Then please give a concrete example, with actual .debs and actual shell > > > commands. > > I'm not going to do debs at this point. (It won't work anyway, because > > of /usr/share/doc) > > So make some fake debs that use /my_usr/share/doc and show that upgrading > and everything actually works. Heck, I've already given you some sample > debs that do this. But your sample debs are orthogonal to the point I'm trying to address. (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. > > I also don't know how to do it as a shell script, > > because gnu mv is horribly broken. Here's a C snippit: > > main() { > > rename("/usr/doc","/usr/share/doc"); > > symlink("/usr/share/doc","/usr/doc"); > > symlink("/usr/doc","/usr/share/doc"); > > } > > This is broken and doesn't work. You've already had three concrete > demonstrations of this. 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. The code above puts doc in /usr/share if possible, and will always have a /usr/doc and a /usr/share/doc pointing to the same location (unless someone's already put in new links or directories, in which case they're on their own.) Packages need to continue to use /usr/doc, but we can transition programs and people to use /usr/share/doc. With that, we've acheived the goal of putting docs in /usr/share for the most part, and we have time to either figure out what to do with dpkg or to come up with another solution. This addresses the partial upgrade issue by continuing to maintain a /usr/doc for use by packages. BUT. This won't work when there's an inconsistent use of /usr/doc and /usr/share/doc. I'm trying to arrive at a solution which can compromise between some of the various demands that people have, and which will be as clean as possible given the situation. If you've got something better I'd be interested to hear it. As I understand the options other people have presented up to this point, we've got: 1. use both /usr/doc and /usr/share/doc; this upsets the partial upgrade people, and worries the UI people. 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 :) 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. 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. (if I've missed any, let me know) To these I'm adding an appeal and compromise: 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 I'd personally be happy to leave the doc dir alone completely until we've got a useful solution, but I'm trying to come up with something that would at least provide fhs-compliance in order to satisfy those who think it's important. I'd honestly like to hear something better. Mike Stone
Attachment:
pgp1pnn9ilPF4.pgp
Description: PGP signature