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

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

 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. 

 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: