Santiago Vila wrote: > Ok, I see. Not dpkg fault. If it helps I can reintroduce /usr/doc in > base-files in etch ;-) I'd prefer the rmdir in the postinst, and not doing it only on upgrade, but unconditionally, and leaving it in for a few releases. That way, whenever a system finally gets the last /usr/doc symlinks cleaned out, it will have /usr/doc removed by a base-files upgrade .. eventually. It's still not uncommon for upgraded systems to have /usr/doc symlinks. For example, they might have an obsolete sarge package like ipchains installed. > 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. I consider this highly unlikely, to the extent that I'm sure I can find hundreds of other situations where we make some assumption about the system that could break if the admin did something similarly unusial. > BTW: Are we talking about the base-files version in etch, for upgrades > from sarge, or the one in lenny for upgrades from etch? (or both) > > I could add the rmdir thing for etch, if the release managers think > we need it. If not, we can leave this to the user. This isn't an RC issue, so I doubt the release managers want to be bothered about it. While I'd prefer to see it fixed for etch, if necessary I can wait one release more. -- see shy jo
Attachment:
signature.asc
Description: Digital signature