[elrepo-devel] a few comment about elrepo's packages

[Phil Perry]

Farkas Levente wrote:
> hi,

Hi, and welcome to the elrepo-devel list :)

> yesterday i look into the packages in elrepo and i have a few comments:
> - it'd be nice to replace the .el5.elrepo tag in the specfiles with %{?dist}
> 

I have no objection to that.

> - most of these modules has no upstream source in this case it'd be 
> better to version it according to the kernel version like the realtek 
> and intel network driver eg. in stead of coretemp-1.1 the 
> coretemp-2.6.27.8 would be more talkative (ie. i prefer that way for all 
> packages).
> 

You have caught us whilst we are still relatively new, and still working 
towards establishing and implementing our standards. Much of what you 
talk about falls under this.

WRT versioning, we have had the discussion and decided against putting 
the kernel version in the package name as it can also mislead users into 
thinking the package is for use with that kernel - not the intended 
message. I must admit that I argued the case for including kernel 
version numbers but we ultimately decided against it after much 
discussion. For those that need to know, look in the changelog as we 
will do our best to provide such information there.

Our (current) policy is to use an upstream version-release when 
available, otherwise to use 0.0-1.el5.elrepo as a starting point. We 
specifically use version 0.0 as opposed to 1.0 to avoid future version 
numbering issues should upstream introduce a version number at a later 
date. We also will include svn datestamps where that is appropriate 
(e.g, kmod-video4linux).

Again, some packages were released before we agreed this standard, so we 
have quite a few kmod-foo-1.x packages were we arbitrarily started at 
1.0-1 and bumped the version-release making it up as we went along. 
Obviously it's difficult to re-version those packages back to 0.0-x once 
they've been released (without using an epoch - yuck!) so we decided to 
just leave it, not worry about it, learn from our mistake and get it 
right going forward.

> - why do you always use a specific kmodtool in stead of the in distro 
> /usr/lib/rpm/redhat/kmodtool? most of the case your version contains 
> only minor changes. 

Because this allows us flexibility to modify the things we need to. We 
implement a number of small bits of functionality in kmodtool:

1. Any package Requires are specified from within kmodtool, not the SPEC 
file. For example, kmod-coretemp Requires an updated lm_sensors.
2. The %files section is expanded to include the .conf override file
3. Blacklisting modules is done in kmodtool, where needed.
4. Provides are updated to allow for yum updates, where appropriate.

None of this can be done using the current distro kmodtool script.

> anyway most of this script is use the "old":
> modules=( \$(rpm -ql kmod-${kmod_name}${dashvariant} | grep '\.ko$') )
> in stead of the
> modules=( \$(find /lib/modules/${verrel}${variant}/extra/${kmod_name} \
>            | grep '\.ko$') )
> the reason why the second is better since the above not working if you 
> would like to install kernel modules during the install ie. you have a 
> kickstart file with kmod packages than the first fail since the rpm is 
> not installed at that stage when the kmod's post section run. ok some 
> kmod's like intel use the later form:-) but it'd be useful to somehow 
> standardize the kmodtool and spec file templates!
> 

The above was updated in the script included in EL 5.3 - we likewise 
subsequently updated our template. Packages built before the update are 
built with the old script (from EL 5.2). Next time they get rebuilt they 
will be updated, but we don't necessarily intend to perform a mass 
rebuild of the whole repo just to get scripts in sync. If people file a 
bug against a specific package because it's not working then of course 
we can rebuild it :)

> - also some of the kmodtool use kabi-modules some the kernel-modules 
> provides.
> 

This resolves the issue of packages not yum updating, but installing 
alongside existing kmods. For kernel specific kmods where you need a 
kmod for each and every kernel this makes a lot of sense, but for 
kABI-tracking kmods we would rather yum be able to update to the new 
version.

However, sometimes upstream change the kernel ABI and not all kmods are 
fully compliant. In these cases where it is likely that kABI 
inconsistency will affect a package (eg, kmod-video4linux), it may be 
more desirable to allow multiple kernel-series-specific versions to be 
installed rather than having yum update them. So we can adjust the 
Provides on a package by package basis to affect the desired yum 
behaviour for that package.

The other reason why some packages provide "kabi-modules" and some 
provide "kernel-modules" is again simply because some packages were 
built before we realised the problem and implemented the fix. Again, as 
they get rebuilt for newer versions we will become more consistent.

> - some kmodtool (like fuse) create file /etc/depmod.d/${kmod_name}.conf 
> but don't include it in the filelist while some (e1000) do not create it 
> but include it in the filelist. imho both are wrong.
> 

Again, we now have a standard that newer packages conform to. Currently 
we provide /etc/depmod.d/${kmod_name}.conf for every package regardless 
of whether {kmod_name}.ko is provided by the current kernel or not (as 
it may be provided in a future kernel).  /etc/depmod.d/${kmod_name}.conf 
is now included in the filelist. Older packages will get updated to this 
specification as they get rebuilt.

> - and the most important why don't you follow the centos kmod scheme ie. 
> using it's own find-requires.ksyms? currently centos' kmod can be used 
> with any centos AND custom centos kernel since you don't remove any kabi 
> tracking info eg coretemp's requires contains:
> ---------------------------------------------
> kernel(rhel5_arch_i386_kernel_ga) = d1c30e0a553e9225eebd1b866e0d3ed7a6154147
> kernel(rhel5_kernel_module_ga) = 1b051ce57d6b18fdf071786f6f7296d3d0ab28f9
> kernel(rhel5_lib_ga) = 088a6b77cde4f82c65b0d7f34802cfa41d209328
> kernel(rhel5_fs_sysfs_ga) = bb43e88ba2b9ebed086513342d9a5a18ed9355a7
> kernel(rhel5_vmlinux_ga) = 2bf444396ff7060828059d7a5379435140aee48a
> kernel(rhel5_drivers_base_ga) = 2490efa8790e7d4b3c7ae4536866c48f1334a356
> kernel(rhel5_mm_ga) = 09f63dfab81bba7e01a2bf693f5ce125db466051
> kernel(rhel5_kernel_ga) = 2cd142708e2d573b2de522df5df87aaeb7c1d298
> kernel(rhel5_drivers_hwmon_ga) = 73ec105e064d9b09c6d44c6584f517b73a7d80ab
> kernel(rhel5_drivers_xen_core_ga) = 5308a7766723999bbea99a33dde1bbb76fee41ca
> ---------------------------------------------
> this is very bad since those who build any kind of custom kerel have to 
> rebuild your src.rpm or rewrite the spec. it's almost the same as not 
> using weak-updates.
> 

I'm not sure I follow you here. We don't follow any "centos kmod 
scheme", we build kmods to the specification of the upstream RHEL5 
Driver Update Programme Technical Whitepaper written by Jon Masters. We 
use find-requires.ksyms provided by the distro. Our kmods should work 
with all el5 kernels that maintain a consistent kABI - that includes 
those from RHEL, CentOS, Scientific Linux and any custom kernels based 
thereon (providing they don't break the kABI). If one builds custom 
kernels without a consistent ABI (i.e, --without kabichk) then it is to 
be expected that kABI-tracking kmod packages won't work for that kernel.

> the best would be some kind of packaging howto with comment and 
> templates which can be used in all kmod packages.
> regards
> 

We have template files for Makefile, kmodtool and SPEC. You can see 
these from any recent package. I agree that it would be a good idea to 
document these on the wiki :)