On Tue 05 Apr 2005, Frank Küster wrote:
> Paul Slootman <[EMAIL PROTECTED]> wrote:
>
> > On Tue 05 Apr 2005, Frank Küster wrote:
> >> David Schmitt <[EMAIL PROTECTED]> wrote:
> >>
> >> I am looking into this, trying to provide a patch - and NMU if Paul
> >> doesn't show up, I really think wwwoffle should go back into sarge.
> >
> > I'm a bit busy with all sorts of things (e.g. new upstream rsync this
> > weekend)... I hadn't really delved into this report yet because it
> > doesn't go wrong for me, actually...
>
> It is easily reproducibly, and it is release critical. We should really
> try to fix this and get wwwoffle back into sarge (you didn't miss that
> it was removed, did you?).
I did actually. I would have expected an email, or at least a message to
d-devel-announce with a list of removed packages. That sucks.
Thanks for bringing it to my attention!
> >> missing. I would not take "preserve user modifications" too literally
> >> here; in fact I doubt that these files are really configuration files -
> >> who would want to configure a 1x1 pixel png file?
> >
> > Many people.
> > In fact, I once replaced it with a debian banner, and it took a while
> > before people realized it was a replacement image, and not in fact a
> > proliferation of debian propaganda.
>
> Where do these images show up? If you think that many people do
You list sites that are not be be accessed; the default action (for
images, e.g. banners from doubleclick.net) is to replace the image that
should have been fetched with the transparent 1x1 image. By putting your
own banner there, you don't have unexpected white areas.
> >> > The following code is AFAICS not conditional upon first installation,
> >> > thus
> >> > overriding a local admin who has intentionally removed the link.
> >> >
> >> > Line 257:
> >> > | perl -i.bak -pe 's/^(\# WWWOFFLE - World Wide Web Offline Explorer
> >> > - Version).*/$1'" $config_version/" $CONFIG
> >> > | if cmp -s $CONFIG $CONFIG.bak; then mv -f $CONFIG.bak $CONFIG; fi
> >> >
> >> > If the perl doesn't modify the config, this will kill the symlink:
> >
> > Will it? AFAIK perl -i.bak will MOVE the original file to .bak; moving
> > it back will hence preserve the symlink.
>
> If the files are equal (if is true), then the symlink, the bak file,
> will be moved back again. But if wwwoffle.conf has been changed, then
> it will be an ordinary file, and the symlink is the bak file which isn't
> used.
Yes, as I just wrote to David, that's not what the text said:
> >> > If the perl doesn't modify the config, this will kill the symlink:
> > Replacing the wwwoffle.conf with a symlink would seem pretty silly
> > anyway, and I wonder as to what extent such actions need to be
> > supported.
>
> I do it, and I do it with many files. Obviously others have noted this,
> too.
Please enlighten me, why? What are the advantanges?
> >> > Line 354:
> >> > | if [ ! -f $OPTIONS ]; then
> >> > | cp -p /usr/share/wwwoffle/default/wwwoffle.options $OPTIONS
> >> > | fi
> >> >
> >> > This too is not special cased to the not-upgrading case.
> >
> > So what?
>
> If the local admin has removed the file, the maintainer scripts have to
> respect this and keep it removed - just as dpkg does it. See the
> policy.
See my other message to David.
> >> > Line 368 and 372:
> >> > | perl -i -e 'while (<>) { next if /htdig/; print; }' $OPTIONS
> >> >
> >> > This skips _all_ lines containing 'htdig' including comments
> >
> > Where does it say it's safe to use comments in that file? See man
> > wwwoffle.options
>
> The manpage only says that comments can be used to comment out ppp.
> Since it even doesn't say what is the comment sign, one should safely be
> able to assume that it has a standard behaviour. And this would include
> to be able to add textual comments.
OK...
However, not related to the RC bug. I suggest that an NMU to fix an RC
bug should not also change all sorts of other things.
(Ah, I see your comment later on)
> >> - the directories in /etc/wwwoffle/html should be shipped in the deb
> >>
> >> - all those symlinks are in fact not configuration "files". Of course
> >> it alters the behaviour of the package if RefreshFormError.html points
> >> to something else than the file shipped in the deb, but this is not a
> >> usual configuration task - it's rather something that one would
> >> normally achieve by patching the package.
> >
> > It was requested that it was done this way, so that individual files
> > could be replaced at will. It works, so why mess with it? What has this
> > to do with this bug report?!
>
> It will recreate the whole symlink farm if it has been deleted.
> Formally, this violates Policy 10.7.3. In my opinion, this is not
> release-critical, because
>
> - I don't really see how this should be needed to configure, and
>
> - I think maintainer scripts should not preserve local changes if they
> would just f*ck up the package.
>
> Therefore I think we should keep this as it is.
Good.
> >> > Line 516, ff:
> >> > | rm -f nohup.out
> >> > | nohup chown -R proxy:proxy /var/cache/wwwoffle/.
> >> > /var/lib/wwwoffle/. >/dev/null 2>&1 &
> >> > | sleep 1
> >> > | rm -f nohup.out
> >> >
> >> > This deletes nohup.out in the current directory, which could be not from
> >> > wwwoffle, which could also be created in $HOME, but is not created by
> >> > nohup anyway because of the redirection.
> >
> > You missed the "cd /var/cache/wwwoffle/temp" 1 line higher...
>
> On the one hand, this handling of nohup.out is completely useless, since
> this file will always be empty because of the redirections. On the
> other hand, if for some reason /var/cache/wwwoffle/temp is not writable,
> nohup will write to $HOME/nohup.out, which is not what you want. The
> most probably reason for not being able to write would be "no space left
> on device".
Ah, didn't think of the ENOSPC case. But if /var/cache is full, you've
got more problems on your hand :)
> Again, this is probably a bug, but by far not release-critical. If you
> insist on this behavior, well, please keep it.
>
> >> I'll just remove the nohup.out removals.
> >
> > Why? Again, what has this to do with this bug report?
>
> Nothing. But this bug has been open for 6 weeks, and there was no
> reaction at all from you, the maintainer. Therefore I assumed that I
> would have to do an NMU. Just today or yesterday it has been complained
> on -devel that when NMUs fix RC bugs, they often fail to otherwise care
> for the package. In a normal situation, I would have kept my proposals
> for an NMU as small as possible, and I assume David would have done the
> same. Here, however, it seemed reasonable to generally look over the
> maintainer scripts.
Someone's always complaining; doesn't mean they're right.
I'd say: NMU for the RC stuff only; after a suitable period, other
things could be done.
> By the way, it's fairly standard to talk about related issues in one
> mail to a bug report; if it turns out that there are separate bugs, the
> bug can be cloned and retitled for the other (in this case, less severe)
> issue.
>
> In the end let me say that I'm glad that you finally found time to look
> at this!
No excuse here... however, I saw the lengthy followup to the bug report,
and when I'm busy I postpone such long messages, because they take too
much time to look at properly (thus the well-intentioned good look at
all the maintainer scripts actually served to distract me, I thought
this can't be RC because there's no way that so much would be in
violation of policy).
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
