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