[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/doc



Adam Heath wrote:
> So, you'd rather see a half-empty /usr/doc, which is not very useful, then to
> have a script, that links /usr/doc to share/doc, and would not cause any loss
> of functionality?

> /usr/doc is much shorter to type, than /usr/share/doc.

No, I want to see no /usr/doc. If you want to make some symlink be my guest,
but /usr/doc is a FHS violation. 

The transition plan, which you have had 3 years to comment on, specifies
that,

    Thus, potato+1 (woody) ships with a full /usr/share/doc, and a
    /usr/doc full of symlinks.
 
    3.   At a later date, another policy (say, 4.X) shall ask for
            packages to no longer provide the link (and possibly remove
            links from /usr/doc). We can also provide a script (possibly
            in base-files postinst) that rm's symlinks from within
            /usr/doc. woody+1 may ship with such a script. (there was a
            proposal as well that potato+2 (woody+1) ships with just the
            prerms, and not the base file script, and potato+3 ships
            with the base-file script, but I am not sure this long a
            reversion period is required).

The aim of this transition has never been to end up with a FHS-violating
/usr/doc symlink, and I protest the idea of supplying one being dragged
in at this late date. If you are unable to change your habits, you can
of course set one up locally. Removing all of /usr/doc and making such
symlink reportedly works.

If someone is interested in writing and testing a /usr/doc nuking script
and getting it into base-files, be my guest but do note the past threads
on the topic of the pitfalls of such a script.

In the meantime, I would like to move forward with this transition
before we embark on other changes like gcc 3.0 recompiles. That is all.

-- 
see shy jo, who had almost thought we could come to a sensible decision
            in reasonable time on this list for once. More fool he.


-- 
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: