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

[Fedora-packaging] Re: atrpms kernel modules



On Fri, Jul 21, 2006 at 05:51:10PM +0200, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> >> I don't want to reply to the other aspects of this mail -- I don't think
> >> it makes to much sense now and prefer to wait for the docs from Axel.

Well, maybe there won't be any docs, we should really decide on the
uname -r thing first, otherwise the docs will be invalid and
unneccessary.

> > No, I don't think we talked past each other, you are giving a perfect
> > example outlining the design bug of any non-uname-r-in-name scheme.
> 
> Well, you said "Suppose you have two active kernels (say 2.6.16 and
> 2.6.17 or xen0 and non-xen0 etc.) [...]e.g. at least one kernel stay w/o
> any kmdl[...]" above -- and xen0 and non-xen0 work fine with the scheme,
> both have a module.

OK, forget about the kernel flavours, I noted that further below, but
the bigger bug is still in place: Nuking of kernel modules of all
previous kernels including the one currently running and installing
the next kernel.

> Well, seems to be a bug for you. Okay, noted. I'd consider is as an
> minor annoyance. And it seems Jack Neely is working on getting it fixed.

He can't fix it on rpm level, and therefore each any every depsolver
needs patching, will he do that for all major 4
(yum/smart/apt/up2date), or will we have to say don't use depsolvers
2-4 and any other future depsolver/applet because they don't fix the
breakage we introduced at rpm level?

And I stongly disagree with calling silently removing kernel modules
for all installed kernels a "minor annoyance" (?). When upgrading to a
new kernel one of the "old" kernels is by definition the one you are
currently running. So nuking your display driver, maybe even your
storage access (imagine ISV's 3w*, qla*) while upgrading is a critical
bug IMO.

> > You don't want to only support the rpm-latest kernel,
> 
> To support only the latest kernel was a decided early in the kmod
> discussion. That might have influenced the kmod standard.

Maybe, but that's a wrong decision. It can only be decided that way if
the previous kernel is also immediately obsoleted in the sense that it
shouldn't even serve as a fallback anymore. That's a policy that can't
go through. And having one policy for the kernel and another for
modules is wrong, too. Imagine a policy of "we support the previous
kernel for some transitions time, but only stripped from it's kernel
modules?"

> > In fact the above is not to be layed in the future, but it's the
> > current situation w/ for example livna, or not? Aren't there any livna
> > reports that they lost their nvidia driver for old kernels while
> > updateing their system?
> 
> Nobody reported a bug yet. And the nvidia driver is a good example: we
> even have explicit "Obsoletes" in the spec to make sure old modules
> always get removed because nvidia-1.2.3 only works with
> kmod-nvidia-1.2.3, but not with kmod-nvidia-1.2.2

That's different, you are referring to module's version, not the
kernel's. It's the kernel's version (e..g uname -r) that gets in the
way.

> >> No, both the up and the smp-kernel still have their modules.
> > And the reason is kernel flavour disambiguation through the name. Add
> > the kernel's version to the name and you'll fix the bug mentioned
> > above. And suddenly it's a uname-r-in-name scheme again and very close
> > to kmdl systems (so let's pick that design and be all happy).
> 
> And it also needs special support in depsolvers so you get all
> kernel-modules together with a kernel update.

No, that's an unfair comparison.

o Special support for kmdls is far easier to implement:
  No need to introduce special non-rpm versioning, half the
  work is already done by natural rpm ordering, only the
  coinstallation upon new kernel installs needs to be done. Remember
  the the 9-liner in bash? That's all there is to it, port that to
  python and let someone who has looked at yum plugins looks over it
  for a minute and you're ready. Due to it's simplicity it's is also
  rather bug-free from the beginning.

o Not having special support for kmdls isn't as critical:
  The worst case is that the new kernel has no initial kmdls. But
  upgrading of old kmdls works as expected and there is no danger of
  nuking away unrelated kernel modules.

IMO these make a very large difference in the quality, neccessity and
ease of implementation of "required special support" in both schemes.

> And you need to maintain a lot of obsoletes to get old kmods removed
> that are incompatible with the updated userland packages.

No, that's not neccessary, if you have the proper dependencies in
place, which the kmdl scheme automatically has.

> Or you need to build kmods for each and every kernel that ever
> shipped -- that would take to long (and they are often not available
> anymore).

No, that's also not neccessary. You only build for the kernels you
care about, e.g. the ones that the buildsystem considers still
supported in whatever sense (e.g. exist in updates-relased).

> > So, do we at least agree that the current kernel modules scheme breaks
> > on rpm CLI level?
> 
> No.

Not being able to use rpm CLI, and if used using to either (partial)
module overwrites or nuking of old kernel modules is no breakage?

Well, we really differ in opinion here, I consider this a big design
flaw to drop direct rpm support or to allow for overwrites/nuking to
happen.

> > Neither rpm -i, nor rpm -U could get you out of the
> > above (typical!) situation.
> 
> I don't consider it a big problem.

So what's your cure of the problem? Disallow using /usr/bin/rpm?
Moving it away and only allowing access through yum?

We know rpm needs higher level tools to really manage the packages
including net access to packages, but until now it's been an iron rule
to remain rpm compatible (which means rpm -U/-i/-F should be
applicable).

Aynway if there is an unmovable blocker/veto by someone that the name
may only contain kernel flavour, but no further uname -r, and he/they
cannot be convinced otherwise the cause is lost right from the start.

Before losing more time into this, this pricipal issue should be
resolved (maybe by a vote on next Thursday), as my doc work will be
wasted (in this scope) right from the start.

Thorsten, besides commenting on this mail, would you have time next
Thursday 1h before the fesco meeting to join #fedora-packaging for
this?
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpZH0Pq8qDI8.pgp
Description: PGP signature


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