Bug#345067: [Yaird-devel] Bug#345067: ide-geenric inclusion even if it doesn't exist.

[Sven Luther]

On Fri, Feb 03, 2006 at 12:33:12AM +0000, Stephen Gran wrote:
> This one time, at band camp, Sven Luther said:
> > On Mon, Jan 30, 2006 at 01:11:44PM +0100, Jonas Smedegaard wrote:
> > > On Sun, 29 Jan 2006 15:20:34 +0100
> > > Sven Luther <sven.luther at wanadoo.fr> wrote:
> > > 
> > > > i, wearing my powerpc debian kernel maintainer hat, know that
> > > > it is not needed on powerpc.
> > > 
> > > This indicates that you are talking about a single kernel build - the
> > > one provided by the kernel team, not powerpc kernels in general.
> > 
> > Jonas, can you please explain me how you can come to the conclusion that
> > ide-generic is *NEEDED* on powerpc, if there is at least one kernel config
> > which does not have it and works perfectly ? 
> > 
> > I think you are just arguing for the sake of arguing, and failing to even try
> > to understand the issue at hand ? 
> 
> Oh look, why are you still fighting about this?  It seems to me that the

This is also what i don't understand. Jonas is finding (bad) excuses not to
fix the issue.

> real problem is that the via module doesn't declare a relation to
> ide-generic in situations where it actually does need it.  Why not fix

Nope, the bug is that for some obscure reason on some obscure hardware there
seems to be a problem with via-ide not working if you don't have ide-generic
loaded. Instead of investigating this and fixing it properly in the kernel, a
hack was added to yaird, which broke the power/pegasos case, which works fine
without ide-generic, and thus doesn't need it.

What i don't understand though, is since it is shown that via-ide works on
powerpc without ide-generic, whyever is jonas making such a fuss over applying
the 3 line fix which simply disable the hack on powerpc. And when we discussed
this face to face, he didn't even seem to be able to consider it, and only
mentioned that it 'may' break other stuff, without being able to show me even
a remotely possible example of such breakage, and when i tried explaining this
to it, he went emotional and almost violent (and we were even asked to leave
the room), so i don't think this has a solution.

> the kernel, so that yaird doesn't have to bend over backwards?  Not that
> I really care either way, but it does seem to me to be cleaner to fix
> the underlying problem rather than adding increasingly nonsensical
> special case code somewhere else to work around it.

Indeed, but in the meantime, we have a hack in yaird which breaks powerpc.

> > > Yaird is a general tool for ramdisk generation. Not fitting in with
> > > some grand plan of the kernel team possible is brokenness of the tool,
> > > but not an RC bug. So thanks for lowering the status, Sven.
> > 
> > Sure, i guess this means my vote will have to go for no more supporting yaird
> > as default ramdisk generator in these conditions.
> 
> And, so?

The problem goes away, nobody uses yaird anymore, and so nobody needs to care
about its brokeness, or the inability of the maintainer to even consider
trivial fixes like this one without weeks and month of flamewar.

> > > And could we please now look at this as a non-urgent matter?
> > > 
> > > I still suspect that your proposed fix, Sven, can hurt in cases other
> > > than the specific one you know and care about.
> > 
> > This opinion of yours will only be acceptable if you can bring me a single use
> > case scenario where this is the case.
> 
> It will hurt in the case that one day, someone will build a kernel image
> on ppc that needs ide-generic, and they will have no idea why yaird

And, please tell me what scenario can mean that ide-generic is *NEEDED*, since
we have proven with the current powerpc kernel that it is not *NEEDED*. It may
be usefull or possible to build it, but not *NEEDED*.

> won't load the module even though they told it to.  This kind of special
> case workaround is a hack.  Fix it where the problem is instead of
> wasting all this energy.

Bullshit, the loading of ide-generic is a hack in the first place, so i just
disable the hack. I guess the proper fix would have been to conditionally use
the original hack only on x86 in the first place, and then you could use this
argument against the original hack.

Friendly,

Sven Luther