On 22 Aug 2000, Manoj Srivastava wrote:
> I see woody release and making not having docs in
> /usr/share/doc/<pkg> as an RC bug as being the stick that shall
> ensuer compliance (I currently have 170 packages on *my* machine that
> are not compliant).
> __> zgrep ^usr/doc Contents-i386.gz | awk '{ print $2 }' | sort -u | wc -l
> 737
A recent Contents-i386.gz gives me
930 packages when looking for usr/doc and
3565 packages when looking for usr/share/doc.
There are 72 packages containing both usr/doc and usr/share/doc, even
if we ignore this fact, we would have:
3565/(3565+930) = 79% of packages already use /usr/share/doc.
> I suggest that we should have significantly less than 737
> packages that are non conformant before we decree the transition is
> complete.
This is exactly where I think there is a major flaw in the original
plan: Waiting for all packages to implement the symlinks *before*
declaring them all deprecated is like waiting for packages linked
against ncurses3.4 to be recompiled against libncurses4 before
recompiling them against libncurses5.
The logical thing to do would be to compile them against whatever
libncurses is the latest.
There are about 20% of packages still using /usr/doc. If we modify
debhelper and debmake now, and stop requiring symlinks, we can expect
woody to be fully FHS compliant regarding /usr/share/doc, and only 20%
non-compliant regarding still existing symlinks.
I agree that if you want to have a system which is a mix of potato and
woody *and* expect everything to be in /usr/share/doc you would have
to upgrade some more packages, but this does already happen when we
have a libc6 in unstable which is not forward compatible with the one
in stable. Normal people is already used to that sort of things, and
it is not considered as a "bug".
In either case, the bug would be in the packages in potato still
using /usr/doc. It would be funny that we have to keep the symlinks
in woody to be compatible with this "bug".
