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

Re: Bug#322762: no blocking bugs anymore



On Fri, 5 Jan 2007, Joey Hess wrote:

> Santiago Vila wrote:
> > Well, what I see is that after an upgrade from sarge to etch, the user
> > may have an empty /usr/doc. But even in such case, it is not base-files
> > business to remove symlinks indiscriminately in /usr/doc, as they
> > could be there because the system admin puts them there deliberately
> > for whatever reason.
> 
> How would you feel about removing only broken symlinks?
> 
> if [ -d /usr/doc ] && [ ! -L /usr/doc ]; then
> 	find -L /usr/doc -maxdepth 1 -mindepth 1 -lname \* -print0 | xargs -0 rm -f
> 	rmdir --ignore-fail-on-non-empty /usr/doc 2>/dev/null
> fi

That would be still be dangerous, and it would also be trying to fix
bugs in other packages.

What if the system admin has a symlink in /usr/doc which points to a
removable volume which may or may not be mounted? We just remove it
anyway, without any questions?

There may be symlinks in /usr/doc mainly for two reasons: Because
the user created them, or because some package forgot to remove them.

The problem is that there is no simple way to know which is the case,
and I hope we agree that we don't want to implement a complex solution
for something which is not such a big problem.

If the user created the symlink, it should be respected as much as
anything in /usr/local, for example. If some package forgot to remove
it, the buggy package should be fixed.

If base-files had to care about packages not removing symlinks
properly, that would be like hiding a problem instead of actually
fixing it, and "Debian does not hide problems".

To summarize: Each package should care about their own symlinks, as we
agreed to do a lot of time ago.


[ The directory /usr/doc itself is different, as you have clearly shown ].



Reply to: