Re: Vanishing /usr/doc symlink
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
Santiago> Manoj Srivastava wrote:
>> >>"Raul" == Raul Miller <moth@debian.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;
>> fi
>> 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
Santiago> debhelper,
Standards and policy can not merely concern themselves with
the most common case. Policy is not meant only for people who use
debhelper.
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
like this.
We have a plan. Lets not jump the gun.
manoj
--
Mother told me to be good but she's been wrong before.
Manoj Srivastava <srivasta@debian.org> <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
Reply to: