[ATrpms-devel] Re: Changing foo-kmdl- to kernel-module-foo-?

[Axel Thimm]

Hi,

thanks! :)

On Sat, May 29, 2004 at 11:17:25AM +0300, Panu Matilainen wrote:
> On Sun, 2004-05-16 at 12:43, Axel Thimm wrote:
> > On Thu, May 06, 2004 at 11:05:59AM +0200, Axel Thimm wrote:
> > I started switching the scheme - builds for fc1 are now
> > kernel-module-foo, for the older releases the builds are still in
> > progress.
> > [...]
> > Speaking of apt-get, Panu, could you extend the lua-kernel-and-
> > kernel-modules-upgrade script to also seek for foo-kmdl-.*
> > (independent of "smp" existence and position) and add these to the
> > candidate upgraders for kernel modules? Is that possible? If yes,
> > many thanks in advance and please post on atrpms-devel at atrpms.net
> > for us to pick it up and test it <8-)
> 
> Hum... the new atrpms naming, or actually the provides in those packages
> is oh-so-close-but-not-quite to the fedora.us provides, causing some
> extra headache. Namely the missing bit is a provide of the package name
> *without* `uname -r` appended, eg for kernel-module-bttv there "should"
> be a provide 
> kernel-module-bttv = 0.9.15-36.rhfc2.at (or bttv-kmdl =
> 0.9.15-36.rhfc2.at)
> instead of, or in addition to this:
> bttv-kmdl-2.6.5-1.358 = 0.9.15-36.rhfc2.at

Does this need to be versioned?

Not having versioned not-kernel-adorned provides is by
design. Otherwise newer rpms (I think FC1 upwards) are just too happy
to remove older kernel modules from other kernels
(e.g. bttv-kmdl-2.6.5-1.358 = 0.9.15-36.rhfc2.at will remove
bttv-kmdl-2.4.xxx = 0.9.12-xxx), which is not intended.

Therefore ATrpms concatenates the above with a hyphen to avoid the
triggereing of this new rpm "feature".

If the fedora.us policy is to provide versioned, but kernel-agnostic
rpms, they should be warned about this. For newer rpms it is like
calling the package itself "kernel-module-bttv" with the known
consequences of cross-kernel upgrades.

> Oh well, at least the basics seem to be working now:
> [root at chip root]# apt-get install bttv-kmdl
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Selecting bttv-kmdl-2.6.5-1.358 for 'bttv-kmdl'
> Selecting kernel-module-bttv-2.6.5-1.358 for 'bttv-kmdl-2.6.5-1.358'
> The following extra packages will be installed:
>    kernel-module-bttv-2.6.5-1.358 (0.9.15-36.rhfc2.at)
> 
> [root at chip root]# apt-get install kernel-module-bttv
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Selecting kernel-module-bttv-2.6.5-1.358 for 'kernel-module-bttv'
> The following extra packages will be installed:
>    kernel-module-bttv-2.6.5-1.358 (0.9.15-36.rhfc2.at)
> 
> I'm more than a bit doubtful about the dist-upgrade case however, this
> doesn't look quite right:
> [root at chip root]# apt-get dist-upgrade
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Calculating Upgrade... WARNING: kernel-module-bttv-0.9.15-36.rhfc2.at
> not available for kernel 2.6.6-1.383!
> Done
> ...
> 
> It *might* work just fine nevertheless, but I'm not 100% sure I can fix
> it if it doesn't, without the additional provides. Let me know how it
> goes...
> 
> Updated script with atrpms-compatibility at
> http://laiskiainen.org/apt/lua/upgrade-virtual/, just remember to
> uncomment the last two lines in upgradevirt.lua to enable -kmdl parsing
> (not sure if that works in the smp-case, test results welcome..) and the
> TranslateArg script slot which is necessary without the "missing"
> provide.

Above all a thousand thanks! :)

Would it be possible to simplify the algorithm to select all packages
matching "^kernel-module-\([^-]*\)($|-)" and try to install
kernel-module-\1-<uname -r of upgrading kernel>? This would work for
fedora.us, ATrpms, PlanetCCRMA, freshrpms and Dag, and also even
when/if fedora.us removed the provides due to the arguments given
above. At least by now we have confidence that the
kernel-module-foo-<uname -r> naming/versioning is quite solid (until
proven otherwise ...).

Maybe the script could then also examine for the regexp
"^\(.*\)-kmdl-.*" in a second pass to collect legacy ATrpms users
(would probably be copy and paste of the first pass).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040529/06e05a81/attachment.bin