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

[Farkas Levente]

On 08/29/2009 09:55 AM, Phil Perry wrote:
>> can i get an account?
>> i'd like to search through all packages kmodtool and see the differences...
>>
>
> We need to think what we are going to do with respect to accounts. At
> the moment I think we only have admin accounts, and obviously not
> everyone needs to be an admin.
>
> Akemi - can we set up an account type for contributors/packagers?
> Something with unrestricted viewings and that can create and modify content?
>
> With respect to kmodtool, we (well, Alan mostly) have now updated the
> vast majority of packages to use the new kmodtool template. We don't
> have a centralized build system so the only way to look/diff kmodtool
> for all packages is to pull the SRPMs.

but at least a common cvs, svn, git repo would be useful for the spec 
file, kmodtools and other additional sources and patches. is anything 
like this exists?
the reason why i'd like to see all kmodtool to search for all required 
features and try to implement one common kmodtool which has all the 
required features if it's possible or see why it's not possible.
i'd rather send patches then have write access and checkin myself.

> In summary, the main differences over this distro shipped kmodtool are:
>
> 1. Provides:         kabi-modules = ${verrel}${variant}
>
> kmodtool normally has a Provide for kernel-modules that prevents yum
> from updating kmod packages. However, for a kABI tracking kmod package,
> updating (rather than installing kernel dependent versions) makes sense
> so we changed the Provide to kabi-modules to facilitate this behaviour
> in yum.

that's a nice feature. although it's a yum bug. it's not documented and 
not working as should have to be. even if a package provide a 
kernel-modules it should have to updating. i already fill a bug about it 
#502140 but no one realy care about it.

> However, the kABI does occasionally change, and if we know (or suspect)
> the kABI might break for a particular package then, at present, we don't
> set kmodtool to update and would rather build and issue a new package
> built against the newest base kernel. An example of this is the
> video4linux package.

if we create separate subpackages in this case as i wrote in my other 
mail then it can be also updating so the kabi-modules provides can still 
be used (ie. we can use one common kmodtool).

> and that's basically it. Our philosophy has very much been to work with
> the tools Red Hat provides us as far as possible. The changes we make to
> kmodtool above are as minimalistic and non-intrusive as possible, and
> implemented in such a way as to be universal for all packages.
>
> Our hope is that kmodtool will grow to become more flexible in RHEL6,
> but I doubt Red Hat will no make significant changes for 5.x.

if it's non-intrusive and rh doesn't support kmods anyway may be it can 
be pushed to 5.x too.

> One of the biggest issues we have at present is how to handle packages
> where the kABI breaks. In an ideal world the kABI would always be
> stable, but experience has taught us that doesn't happen. Dag has
> suggested a mechanism for packaging multiple versions of the same
> module, built against each base kernel for where there is kABI
> breakages. The present solution is to revert to building kernel (series)
> dependent packages to support older kernels.

as i wrote earlier it can be do.

-- 
   Levente                               "Si vis pacem para bellum!"