Joey Hess wrote:
I note that we still arn't 100% sure we've caught every last upgrade
issue involving /usr/doc, since AFAIK puiparts has not been used to
test upgrades of everything.
Pity :(
Also, I see that there are still some lintian warnings about it at
Hi,
Set any bugs about /usr/doc stuff to being blockers of this bug report.
Use this as a tracking/coordination bug for the remainder of the transition.
Note that once this transition is complete we will need to do something
in base-files to remove the /usr/doc directory, if it is empty. It
Thijs Kinkhorst wrote:
Well, today I have fixed the last two remaining bugs that blocked this
bug (I'll have to followup to them to see whether the fixes will get to
Etch, but that is not really on topic for this bug per se).
Excellent.
I note that we still arn't 100% sure we've caught every
On Fri, 5 Jan 2007, Thijs Kinkhorst wrote:
Hi,
Set any bugs about /usr/doc stuff to being blockers of this bug report.
Use this as a tracking/coordination bug for the remainder of the transition.
Note that once this transition is complete we will need to do something
in base-files
On Fri, 5 Jan 2007, Joey Hess wrote:
Yes, I think it's time to reassign it to base-files, to get the
directory removed on upgrade if it's empty.
Please don't. Dpkg already does that. See my previous message.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Santiago Vila wrote:
Please don't. Dpkg already does that. See my previous message.
It doesn't seem to in all cases, I have empty /usr/doc directories on
some systems.
--
see shy jo
signature.asc
Description: Digital signature
On Fri, 5 Jan 2007, Joey Hess wrote:
Santiago Vila wrote:
Please don't. Dpkg already does that. See my previous message.
It doesn't seem to in all cases, I have empty /usr/doc directories on
some systems.
Then it's dpkg fault, in which case you should reassign it to dpkg.
The purpose of
What's going on is that a base sarge system looks like this:
kodama:/usr/doc# ls -l
total 0
lrwxrwxrwx 1 root root 15 Jan 5 22:41 at - ../share/doc/at
lrwxrwxrwx 1 root root 17 Jan 5 22:41 cpio - ../share/doc/cpio
lrwxrwxrwx 1 root root 21 Jan 5 22:41 ipchains - ../share/doc/ipchains
On Fri, 5 Jan 2007, Joey Hess wrote:
What's going on is that a base sarge system looks like this:
[ snipped datailed explanation ]
Ok, I see. Not dpkg fault. If it helps I can reintroduce /usr/doc in
base-files in etch ;-)
The following in base-files's postinst would fix both issues.
if
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
On Fri, 05 Jan 2007, Joey Hess wrote:
The following in base-files's postinst would fix both issues.
if [ -d /usr/doc ] [ ! -L /usr/doc ]; then
find /usr/doc -maxdepth 1 -mindepth 1 -type l -print0 | xargs -0 rm -f
rmdir --ignore-fail-on-non-empty /usr/doc 2/dev/null
fi
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
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
Santiago Vila wrote:
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.
It's impossible to fix a buggy package that is no longer in debian, or
that is no longer
On Fri, 5 Jan 2007, Joey Hess wrote:
Santiago Vila wrote:
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.
It's impossible to fix a buggy package that is no
15 matches
Mail list logo
