[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NPTL support in 2.4 kernel series?

Andreas Metzler <ametzler <at> downhill.at.eu.org> writes:
> > Then one might wonder what is the use of a general "Provides:
> > kernel-image-xy" if one is not to use it.
> No idea.

Then why not remove them since they are prone to generate confusion (as it seems
they did in my case)?

> > > OTOH anybody installing glibc with make-install will get "You shot
> > > yourself" on _any_ report of a problem.
> > That is why I think the comparison is valid. Citing 'accepted and
> > supported practice' does not change its validity, if anything then
> > only whether there should be any consequences...
> I do not understand. What is your reasoning? What is the "why" in "That
> is why I think the comparison is valid"?

Since you started your statement with "OTOH" I thought you were conceding that I
had a point there, maybe I was mistaken...

> > I still don't like this as the only solution, because by default it
> > will break the running setup of people still using 2.4
> > kernels. They'll get the update installed and the package is
> > broken.
> No. They'll see the debconf question, select "abort installation", the
> package will not be upgraded, the package will not be broken.

They still had to download a useless package and do an interactive update. And
if I am not mistaken, their running databases will have been stopped during the
prerm-phase. So all in all, I would not consider this a pleasant experience.

> [...] <ad nauseam>The existence of a kernel-image does nothing
> for your problem, as it does not give you any information about the
> running kernel.</>

I absolutely agree, which is why additional checks are needed. But the existence
of the dependency at least explicitely states a requirement of the package that
is visible before any installation attempt and in many cases will prevent a
futile installation attempt.

Still, judging from everything I read so far, it seems that I am the only one
with such a strict view of dependency handling, so if nobody comes up with
support for my point of view, I will not add the dependency but go for the
debconf solution instead.


Reply to: