Daniel Schepler wrote:
> On Friday 05 January 2007 20:56 pm, Thijs Kinkhorst wrote:
>> Hi,
> It appears that inform's postinst still creates a /usr/doc symlink, and this
> seems to have been missed.
>
> What's the appropriate severity for a bug to be filed against inform?
important
Cheers
Luk
On Friday 05 January 2007 20:56 pm, 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 s
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
> http://lintian.debian.org/rep
Santiago Vila wrote:
> No, the next step is to close the bug and celebrate it.
As love ly as it sounds, I'd like to see what piuparts has to say about
it :)
But att the pace we are moving (piuparts) I expect to fix this in
a different release.
--
ยท''`. If I can't dance to it, it's
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 i
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 instal
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 ther
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 delib
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:
> 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, 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.
>
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
lrwx
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
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:
> 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". Tro
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 ever
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 b
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
18 matches
Mail list logo
