> I'm just trying to get this conversation moving forward again by
> making sure everyone is aware of where the current implementation
> stands. This particular issue seems to be forever stalled in a
> debate over where to start.. policy or tools. I'd hate to see this
Well, we've got a small bit of the functionality in Yum working...if
oddly. I don't mind doing that work but we need some idea of policy
that I can code to. :-)
> conversation frustrated further by an inaccurate accessment of current
> reality. If packagers provided "kernel-modules" the current magic in
> yum would work pretty well for most of the situations an end-user
> would care about. What are the real hold ups here... why isn't it
> good enough to make a policy decision that all Core and Extras module
> packages provide "kernel-modules" and be named
> "kernel-module-whatever" as a starting point to get some packages out?
>
How I would like things to be:
Kernel module packages MUST provide "kernel-modules". Not
"kernel-module". This keeps in line with previous work and already
existing code. This provides will identify to Yum/Plague/Whatever that
this package is a kernel module and needs special treatment.
Kernel module packages MUST require kernel-%{_targetcpu} = ${kver}.
This identifies to Yum what kernel this module works with and will
identify other kernel module packages that need to be removed.
The release tag will be <RELEASE>.%{?kver:.%(echo %{kver} | tr - _)} or
something along those lines. This provides no information to Yum/Plague
but gives the package a unique EVR. Its really hard to correctly parse
information like a kernel version out of the release tag.
I really don't like the kernel-module-foo-source base package that
produces a subpackage of kernel-module-foo. This adds way to much
complexity. The goal here, IIRC, is to be able to have one src.rpm for
all the times that the kernel-module-foo has been rebuilt for each
kernel version/flavor. Being that the release tag already contains a
lot of our magic I suggest we make the release tag be the following.
Release: [release]%{!?sourcepackage:%(echo .%{kver} | tr - _)}
where [release] is the packager's release number of the package.
With this idea we ignore/delete all srpms that are created with rebuilds
of the kerenl-module-foo package. To generate the official srpm the
build system does:
rpmbuild -bs kernel-module-foo.spec [defines] \
--define "sourcepackage 1" [targets]
If this srpm already exists in the repository then ignore it.
Otherwise, you have a new version of the kernel module itself rather
than just 15 hundred rebuilds of it.
Jack
> -jef
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <jjneely@xxxxxxxx>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
