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
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
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
15 matches
Mail list logo
