On Sat, Jul 29, 2006 at 02:52:28PM +0100, Stephen Gran wrote:
> This one time, at band camp, Robert Millan said:
> > On Sat, Jul 29, 2006 at 01:15:27PM +0100, Stephen Gran wrote:
> > > And then use constructs like
> > >
> > > if (which($postinst_hook)) {
> > > ...
> > > }
> > >
> > > I can't remember if you use taint mode and warnings and so forth, but if
> > > you do, substitute an array of known good paths for ENV{"PATH"}.
> >
> > I think it's better (asides from easier) to just not check that, and let
> > scripts fail if something is indeed broken in /etc/kernel-img.conf.
> >
> > Silently skipping broken commands in /etc/kernel-img.conf is not better than
> > failing and letting the user know about it, IMHO.
>
> It currently silently skips them if they are not executable - I'm just
> providing a way to have the same behavior without full paths. Your
> patch changes the behavior of kernel-img handling in a backwards
> incompatible way.
Yes, you're right. Although I was just suggesting to change this behaviour
as well, I don't really mind as long as relative paths can be used.
> > > In any event, I am not sure this is RC, but I'll let manoj deal with
> > > that.
> >
> > It's release critical only on the basis that, without fixing this, a release
> > critical bug in another package (#361929) can't be properly addressed.
>
> RC bugginess is not necessarily transitive, at least IMHO. But as I
> said, this is for manoj to decide.
I think it is by definition. If bug A depends on bug B, and you can't make a
release without fixing bug A, then you can't make a release without fixing B.
Perhaps the RMs have some input about this, too. But I don't find this
discussion very useful anyway. Let's just focus on fixing the problem! :)
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
