Re: Vanishing /usr/doc symlink
>>"Santiago" == Santiago Vila <email@example.com> writes:
Santiago> Manoj Srivastava wrote:
>> >>"Raul" == Raul Miller <firstname.lastname@example.org> writes:
Raul> If it's possible to install woody against potato without errors caused
Raul> by a missing /usr/doc then the tech committee's migration plan is no
Raul> longer needed.
>> Unless one does an audit of the packages (and not jsut
>> packages that happen to be installed on ones machine at the moment),
>> there is no way to be sure of this. As I have said before, current
>> policy makes it perfectly legal to do thisng like
>> if [ -d /usr/doc/$package ]; then
>> rm -rf /usr/doc/$package;
>> ln -sf ../share/doc/$package /usr/doc/$package
>> I, for one, have not done this audit, nor do I have the time
>> to do so. Additionally, several months into the freeze, isn't it kind
>> of late to be changing plans midstream? Policy is frozen. And there
>> is a must requirement for packages to provide the symbolic link --
>> unless you are saying we should just blow the release manager off and
>> the say the hell with the freeze and start over just so we don't ship
>> /usr/doc/ full of symbolic links.
Santiago> What about putting "packages must not depend on /usr/doc
Santiago> being present" in policy and aiming for a /usr/doc-less
Santiago> woody+1 fresh install, then?
Policy is currently frozen. When we come back after woody's
release, removing the need symlink in /usr/doc/ cause would be hihg
on the list to be removed from policy.
Santiago> Regarding the code in prerm and postinst, most people uses
Standards and policy can not merely concern themselves with
the most common case. Policy is not meant only for people who use
Santiago> or cut and pasted from the policy manual, or
Santiago> wrote completely robust postinst from their own, so we
Santiago> can't make a package audit but we can reasonably assume
Again, I think these are assumptions that can't be made when
we are talking policy -- not if we mean to have high quality.
Santiago> that this policy will not force a large number of packages
Santiago> to suddenly be in violation (which is one of the
Santiago> requirements of policy changes).
I would rather not go into another fiasco like we had at the
beginning of the /usr/doc -> /usr/share/doc transformation by being
overly optimistic about the problems that may arise from a change
We have a plan. Lets not jump the gun.
Mother told me to be good but she's been wrong before.
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C