On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now. As for naming, the kernel version needs to be stored *somewhere*. And we need to finalize the naming issue before we can decide what behavior depsolvers need.
But we should really fix the remaining issues with kernel module builds, I'd like to get LIRC modules shipped too, and there may be other stuff queued up from others. Anybody willing to (re)start or join this discussion somewhere? fedora-packaging?
Works for me. Here's my first submission:
https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00965.html
I've had to make a few changes for FC4, and I'll post those later today when I get a chance.
On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now.
I'll screw it once the i586 kernel is screwed from FC :) Seriously, there are cases where i586 and external kernel modules are a valid scenario; for example I think a lot of HTPC/PVR boxes run some VIA CPUs that don't work with the i686 kernel, and having LIRC modules for their remote controls is kind of essential.
But anyway, even in the hypothetical case that i586 would be ignored, I'm not 100% sure how to implement i686 build only for the ix86 family in the build system, while keeping in mind that the modules should probably be built for x86_64 and ppc too. %ifarch %{ix86} \ BuildArch: i686 \ %endif?
As for naming, the kernel version needs to be stored *somewhere*.
Dependencies, surely, but it does not _have_ to be in the package's NVR, as demonstrated by the external kernel module packages in FC4 (eg. GFS-kernel). Having it in the NVR somewhere is useful for humans, and it can be (ab?)used to get depsolvers to do "stuff".
And we need to finalize the naming issue before we can decide what behavior depsolvers need.
Possibly.
On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now.
I'll screw it once the i586 kernel is screwed from FC :) Seriously, there are cases where i586 and external kernel modules are a valid scenario;
As architectures actually are switched outside of rpm-specs (rpmbuild --target=..) this isn't a packaging issue, but actually is a build system issue.
I.e. the buildsystem has to be equipped with means to specify architectures, because rpm specs can't handle it.
Ralf
On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote:
On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now.
I'll screw it once the i586 kernel is screwed from FC :) Seriously, there are cases where i586 and external kernel modules are a valid scenario;
As architectures actually are switched outside of rpm-specs (rpmbuild --target=..) this isn't a packaging issue, but actually is a build system issue.
I.e. the buildsystem has to be equipped with means to specify architectures, because rpm specs can't handle it.
It's also an rpmdb issue as you (or at least *I*) can't have kernel-devel.i586 and kernel-devel.i686 installed simultaneously even though there are no file conflicts between the packages.
On Tue, Jun 28, 2005 at 12:35:14PM -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote:
On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now.
I'll screw it once the i586 kernel is screwed from FC :) Seriously, there are cases where i586 and external kernel modules are a valid scenario;
As architectures actually are switched outside of rpm-specs (rpmbuild --target=..) this isn't a packaging issue, but actually is a build system issue.
I.e. the buildsystem has to be equipped with means to specify architectures, because rpm specs can't handle it.
It's also an rpmdb issue as you (or at least *I*) can't have kernel-devel.i586 and kernel-devel.i686 installed simultaneously even though there are no file conflicts between the packages.
-- Ignacio Vazquez-Abrams ivazquez@ivazquez.net http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
To me this is really a multilib issue. Multiple packages with the same name installed but built for different arches. The spec file needs to be able to require the kernel-devel packages of the same arch as the current build.
Jack Neely
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Tue, 2005-06-28 at 15:09 -0400, Jack Neely wrote:
The spec file needs to be able to require the kernel-devel packages of the same arch as the current build.
Not a problem, one solution already mentioned in this thread: https://www.redhat.com/archives/fedora-packaging/2005-June/msg00020.html
On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
But anyway, even in the hypothetical case that i586 would be ignored, I'm not 100% sure how to implement i686 build only for the ix86 family in the build system, while keeping in mind that the modules should probably be built for x86_64 and ppc too. %ifarch %{ix86} \ BuildArch: i686 \ %endif?
Clearly the kernel buildsystem (I can see this being separate from Plague, at least in the beginning) would have to be able to parse BuildArch properly in order to determine which archs it should be built for. It *may* be possible to leverage rpmlib for this, but I don't have time to look into it atm.
On Tue, 2005-06-28 at 12:39 -0400, Ignacio Vazquez-Abrams wrote:
Clearly the kernel buildsystem (I can see this being separate from Plague, at least in the beginning)
And I can see _that_ happening sometime around FC-8 ;)
AFAIK there's no absolute _need_ to have a separate buildsystem, not even because of the current impossibility to have both i586 and i686 kernel-devel for the same kernel installed at the same time. Just specify for example
BuildRequires: kernel-devel-%{_target_cpu} = %{kernel}
in the module specfile (where %{kernel} is the "uname -r" output for the target kernel, and the correct --target has been passed to the build), and let the depsolver do its job. There are no kernel-devel packages included in the default minimal build roots that could screw this up, right?
If so, a simple (from the module packager POV, dunno about the buildsys side) extension to the current CVS target could be for example:
make build ARCH="i586 i686 x86_64 ppc"
This could be a useful feature for other packages than kernel module ones too, should we ever want to ship eg. something built for i686 in the i386 repo.
As for naming, the kernel version needs to be stored *somewhere*.
Dependencies, surely, but it does not _have_ to be in the package's NVR, as demonstrated by the external kernel module packages in FC4 (eg. GFS-kernel). Having it in the NVR somewhere is useful for humans, and it can be (ab?)used to get depsolvers to do "stuff".
Your kernel module should require the kernel it was built for. Its simple and already common practice. I already have depresolver code that examines the EVR of any Requires that are in the list of packages considered kernel packages.
I strongly oppose having the kernel version/type in the packages NVR. The depresolver should be smart enough to know when to install kernel module packages and in what conditions to erase them. Kernel module packages are never upgraded.
And we need to finalize the naming issue before we can decide what behavior depsolvers need.
I prefer the naming scheme of <foo>-kernel
However the depresolver should not hinge off of a specific naming scheme. Kernel modules should Provide kernel-modules to trigger the extra functionality in the depresolver.
Jack Neely
On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
As an aside, I didn't think Extras was ready to tackle the issue of kernel module packages yet.
Right, at least three issues remain: how to name the modules, how to make depsolvers do the right thing with them, and how to request builds for i586 and i686 from the build system for the same package.
Screw i586 for now. As for naming, the kernel version needs to be stored *somewhere*. And we need to finalize the naming issue before we can decide what behavior depsolvers need.
Actually, no. I'm not going to standardize kernel module packaging _UNTIL_ at least yum is fixed.
Let me reiterate some points that I have made in the past:
- I do not plan to overload the %{name} value for kernel module packages. This means that we will NOT be shoving the kernel version in %{name}. Its ugly, it screws up bugzilla, breaks existing packaging guidelines, and is altogether wrong.
- Given that, we WILL need to put the kernel version (in some part) in either %{version} or %{release}. Let me explain why:
On SMP systems, at a bare minimum, there will be two kernels installed:
kernel-smp-2.6.12-1.1400_FC5 kernel-2.6.12-1.1400_FC5
If we do not use kernel version in either %{version} or %{release}, we'll have no way to generate two packages with unique %{name}-%{version}-%{release} values.
We have to assume that each installed kernel will want to have a matching module addon installed for it.
I originally proposed (back in March) that we put the kernel version in Release. This is a slightly revised proposal.
Name: kernel-module-openafs (where the value in the Name field is the name of the module, prepended with "kernel-module-") Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1") Release: %{kver} (Where %{kver} is the kernel we're building against) Requires: kernel-%{_target_cpu} = %{kver} BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
%{kver} gets passed by the buildsystem, for each kernel found in the branch for which that package is being built. So, for our example kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, respectively. FC4 and newer kernels have this value in the provides for "kernel-%{arch}", so it should not be too difficult for the build system to figure out the correct value for %{kver} from the target kernel package.
There is no need to use dist tags here, since %{kver} includes the dist name.
If a bugfix needs to be made to the package, then the .1 (build revision) is incremented. If a new version of the kernel driver is released, then the first part of the Version is incremented, and the build revision is reset to .1 (if it is not .1).
So, after the buildsystem does its thing, we've generated two new binary rpms:
kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm
Since no previous packages with those n-v-r's exist, yum installs them, just as it would kernels, doing the equivalent of an rpm -i action.
Now, on the system we have all four packages installed:
kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp
But wait, I've found a bug in kernel-module-openafs. Easy enough to fix, I patch it away, increment my build revision to .2, and we now have these new packages available:
kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm
But, here yum doesn't know what to do. We can't do a -i, those packages would conflict with the existing kernel-module-openafs packages. We can't do a -U, because then we'd only end up with one kernel-module-openafs package on the system. What we need yum to do is a special operation that does the following (only for kernel-module packages):
- Does any kernel-module-openafs package exist on the system with the same %{release}? - If yes, remove it (rpm -e). If no, continue. - Install new package (rpm -i).
After this process, the system has:
kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp
Now, if someone is willing and able to write the exception case needed for yum in kernel-module-* packages, then I think we can document the remaining standard bits, duct tape the necessary logic into the buildsystem, and start doing kernel-module-* packages for FC4 and devel.
~spot
On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway wrote:
Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1")
If a bugfix needs to be made to the package, then the .1 (build revision) is incremented. If a new version of the kernel driver is released, then the first part of the Version is incremented, and the build revision is reset to .1 (if it is not .1).
Where do you propose that we put the version number of the module itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in that case?
On Tue, 2005-06-28 at 20:56 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway wrote:
Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1")
If a bugfix needs to be made to the package, then the .1 (build revision) is incremented. If a new version of the kernel driver is released, then the first part of the Version is incremented, and the build revision is reset to .1 (if it is not .1).
Where do you propose that we put the version number of the module itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in that case?
Yes. If you need to use the version number of the module itself without a build revision, then we can use something like:
Provides: kernel-module-openafs-version = 0.6.3
We could also standardize on a macro, something like %{modulever}, define it at the top, then use it throughout the spec file for clarity.
~spot
On Tue, Jun 28, 2005 at 08:14:22PM -0500, Tom 'spot' Callaway wrote:
Yes. If you need to use the version number of the module itself without a build revision, then we can use something like: Provides: kernel-module-openafs-version = 0.6.3
This seems yicky.
What if we do this, and so we're providing kernel-module-openafs-version = 1.3.84, and then the upstream decides to do a bugfix release and call it 1.3.84.1? With your scheme, our old kernel module was *already* 1.3.84.1.
Why *not* just put package release #s in the package release #?
On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote:
- I do not plan to overload the %{name} value for kernel module
packages. This means that we will NOT be shoving the kernel version in %{name}. Its ugly, it screws up bugzilla, breaks existing packaging guidelines, and is altogether wrong.
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
[...]
Oh wait, something else I want to comment on --
Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1")
Ouch -- this won't work. The .1 here will be very very confusing. For openafs 1.3.84, the _package_ release shouldn't be 1.3.84.1 or whatever -- it'll make it hard to match up to the actual source. I think this is *worse* than putting the version in the name.
I think it's better to have this in the release:
Release: %{kver} (Where %{kver} is the kernel we're building against) Requires: kernel-%{_target_cpu} = %{kver} BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
Release: %{realpackagerelease}.%{kver}
'cause hey, that's what the Release tag is supposed to be fore*.
%{kver} gets passed by the buildsystem, for each kernel found in the branch for which that package is being built. So, for our example kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp,
Oh, there's another problem -- can't have a "-" in the release #.
respectively. FC4 and newer kernels have this value in the provides for "kernel-%{arch}", so it should not be too difficult for the build system to figure out the correct value for %{kver} from the target kernel package.
Passed in in a loop from the buildsystem? That seems decent.
My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't.
[...]
kernel-module-openafs package on the system. What we need yum to do is a special operation that does the following (only for kernel-module packages):
- Does any kernel-module-openafs package exist on the system with the
same %{release}?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).
Haven't thought this through completely, but there's one more factor too: kernel-module-openafs-1.3.84 will be required by the openafs-client package.
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote:
- I do not plan to overload the %{name} value for kernel module
packages. This means that we will NOT be shoving the kernel version in %{name}. Its ugly, it screws up bugzilla, breaks existing packaging guidelines, and is altogether wrong.
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
I think it's better to have this in the release:
Release: %{kver} (Where %{kver} is the kernel we're building against) Requires: kernel-%{_target_cpu} = %{kver} BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
Release: %{realpackagerelease}.%{kver}
OK, so lets say we do this.
In this case, we have %{kver} in %{release} to keep %{release} unique (and thus, have unique NVR). However, we can no longer just use %{release} as our check variable in yum. In this scenario, we need to instead make yum check some sort of "magic" provides that only kernel-module packages will have (not as much of a hack as might be thought).
In the spec, we put:
Provides: kernel-module-openafs-kver = %{kver}
Basically, to modify my original yum logic path:
- Does any kernel-module-openafs package exist on the system with the same kernel-module-openafs-kver? - If yes, remove it (rpm -e). If no, continue. - Install new package (rpm -i).
Oh, there's another problem -- can't have a "-" in the release #.
%define cleankver %(echo %{kver} | sed s,-,_,g)
My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't.
Or you could make the userspace gunk in a subpackage. No reason that kernel-module-openafs can't generate both kernel-module-openafs and openafs packages.
You can override the version and release for the openafs package.
Haven't thought this through completely, but there's one more factor too: kernel-module-openafs-1.3.84 will be required by the openafs-client package.
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps the remove, knowing that the install is coming right afterward.
~spot
Haven't thought this through completely, but there's one more factor too: kernel-module-openafs-1.3.84 will be required by the openafs-client package.
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps the remove, knowing that the install is coming right afterward.
umm, what?
no we won't.
we're not adding --nodeps or that tsflag into yum.
-sv
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
Requires: kernel-%{_target_cpu} = %{kver}
In the spec, we put:
Provides: kernel-module-openafs-kver = %{kver}
Or, we just leave that nonsense out and key off the Requires: kernel-%{_target_cpu}
So, once more: - Does any kernel-module-openafs package exist on the system that requires the same kernel-%{_target_cpu} = %{kver} as me? - If yes, remove it (rpm -e --nodeps). If no, continue. - Install new package (rpm -i)
I suspect this is very close to Jack's existing patch.
~spot
On Wed, 2005-06-29 at 08:42 -0500, Tom 'spot' Callaway wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
Requires: kernel-%{_target_cpu} = %{kver}
In the spec, we put:
Provides: kernel-module-openafs-kver = %{kver}
Or, we just leave that nonsense out and key off the Requires: kernel-%{_target_cpu}
So, once more:
- Does any kernel-module-openafs package exist on the system that
requires the same kernel-%{_target_cpu} = %{kver} as me?
- If yes, remove it (rpm -e --nodeps). If no, continue.
- Install new package (rpm -i)
I suspect this is very close to Jack's existing patch.
I suspect that were NOT adding --nodeps.
no matter what.
think again if you think we are.
-sv
On Wed, Jun 29, 2005 at 08:42:10AM -0500, Tom 'spot' Callaway wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
Requires: kernel-%{_target_cpu} = %{kver}
In the spec, we put:
Provides: kernel-module-openafs-kver = %{kver}
Or, we just leave that nonsense out and key off the Requires: kernel-%{_target_cpu}
So, once more:
- Does any kernel-module-openafs package exist on the system that
requires the same kernel-%{_target_cpu} = %{kver} as me?
- If yes, remove it (rpm -e --nodeps). If no, continue.
- Install new package (rpm -i)
I suspect this is very close to Jack's existing patch.
Very. I'm missing a detail or two but I'll get that out tonight.
Jack
~spot
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Folks,
Attached is a patch that implements some of the kernel magic needed by Yum to work with kernel modules as decided on fedora-packaging-list. This keys off of kernel modules requiring
kernel-%{_target_cpu} = %{kver}
Couple points of note:
* You must still have your kernel modules provide "kernel-modules" to enable the install only behavior. However, the code uses the package name "kernel-module-foo" to identify if this is a kernel module.
* The next question is when you do "yum install kernel-module-openafs" which packages do we apply to the system? Not covered by this patch.
Jack
On Thu, 2005-06-30 at 00:06 -0400, Jack Neely wrote:
Folks,
Attached is a patch that implements some of the kernel magic needed by Yum to work with kernel modules as decided on fedora-packaging-list. This keys off of kernel modules requiring
kernel-%{_target_cpu} = %{kver}Couple points of note:
You must still have your kernel modules provide "kernel-modules" to enable the install only behavior. However, the code uses the package name "kernel-module-foo" to identify if this is a kernel module.
The next question is when you do "yum install kernel-module-openafs" which packages do we apply to the system? Not covered by this patch.
As far as I'm concerned, we look at what kernels are on the system (in the rpmdb), and try our best to match them all against the kernel-module-openafs packages in the repo. When we find a kernel for which no kernel-module-openafs package exists in the repo, we throw a warning, but don't exit, and install the ones we do find matches for.
Warning: No kernel-module-openafs package was found for kernel-2.6.12-1.1400spot
I really can't think of a situation in which we would not want to install an addon kernel-module for all kernels installed via rpm.
~spot
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps the remove, knowing that the install is coming right afterward.
In fact, its not even a problem.
skvidal> it's a simultaneous transaction skvidal> if bar (installed) requires foo skvidal> and you're removing baz (provides foo) skvidal> and installing quux(provides foo) skvidal> and it is all in one transaction then there are no broken dependencies spot> ok. :) then its a non issue. skvidal> there's no need for --nodeps skvidal> right but I feel it is a necessity to smack any discussion of --nodeps at all times :)
Consider me duly smacked.
~spot
On Wed, Jun 29, 2005 at 08:48:11AM -0500, Tom 'spot' Callaway wrote:
skvidal> and installing quux(provides foo) skvidal> and it is all in one transaction then there are no broken dependencies spot> ok. :) then its a non issue. skvidal> there's no need for --nodeps
Okay, just to get this all concrete for me....
On the system, we've got:
kernel-2.6.11-1.27_FC3 kernel-2.6.11-1.35_FC3 kernel-smp-2.6.11-1.27_FC3 kernel-smp-2.6.11-1.35_FC3
openafs-1.3.84-1 openafs-client-1.3.84-1
kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3smp kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3smp
If we add a new kernel, say:
kernel-2.6.11-1.40_FC3 kernel-smp-2.6.11-1.40_FC3
Okay, the Magic makes the depsolver pull in
kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3smp
and we're all good.
Okay, but now say there's an updated openafs-1.3.85. So we've got to figure out that:
kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-1_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-1_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-1_2.6.11-1.40_FC3
(plus smp)
And to complicate things, you also have the potential to have to deal with
kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3
and
kernel-module-openafs-1.3.85-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3 kernel-module-openafs-1.3.85-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3 kernel-module-openafs-1.3.85-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3
.
Maybe this'll all work, but, gah. :)
On Wed, Jun 29, 2005 at 08:38:45AM -0500, Tom 'spot' Callaway wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
That can work too -- look at the pump RPM, which only generates subpackages with different names. But I only think this is preferable to putting the package release number in the version -- my preferences is for kernel and package release number to both go in the release.
Release: %{realpackagerelease}.%{kver}
OK, so lets say we do this. In this case, we have %{kver} in %{release} to keep %{release} unique (and thus, have unique NVR). However, we can no longer just use %{release} as our check variable in yum. In this scenario, we need to
Right -- anything that wants to do something smart with these packages will have to be smart about it. I think it's better to require whatever smartness in as few places as possible, even at the price of requiring more of it in those places. Redefining what 'version' means to mean "somes the upstream version, sometimes some numbers we made up" seems a lot worse in general.
And, the "cleanver" thing to get rid of the '-' already requires some parsing. As much as I hate _ in package names, we could do:
Release: %{realpackagerelease}_%{cleankver}
or maybe
Release: %{realpackagerelease}.kver%{cleankver}
(Ugh, very long and ugly, though.)
instead make yum check some sort of "magic" provides that only kernel-module packages will have (not as much of a hack as might be thought).
The more I think about this (Jack's) approach, the more I feel okay about it. Maybe it's contagious. :)
[...]
My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't.
Or you could make the userspace gunk in a subpackage. No reason that kernel-module-openafs can't generate both kernel-module-openafs and openafs packages.
That seems backwards. Right now, the kernel modules are a subpackage of the openafs package -- making the package kernel-module-openafs seems like putting the cart before the horse. (Why would openafs-server be a subpackage of that, for example?)
You can override the version and release for the openafs package.
Except, if we're building for five different kernels, each of those would then generate the identical openafs-server, openafs-client, and openafs packages. At the very least, that's a lot of wasted CPU.
Haven't thought this through completely, but there's one more factor too: kernel-module-openafs-1.3.84 will be required by the openafs-client package.
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps the remove, knowing that the install is coming right afterward.
Ow, must we?
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage".
My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't.
Or you could make the userspace gunk in a subpackage. No reason that kernel-module-openafs can't generate both kernel-module-openafs and openafs packages.
What about archs? We probably don't want i586 and i686 userland openafs stuff, but just i386. Choices:
1) Just ship userland as i586 and i686 too 2) Split userland and module SRPMS 3) Conditionalize whether to build the modules or the userland or both based on some passed in build options (rpm.livna.org uses "--without modules" and "--without userland") 4) Hardcode our assumptions based on arch somewhere, eg. if target=i586 or i686, no userland will be built, and if target=i386, no modules will be built
2) gets my vote.
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
Just ship userland as i586 and i686 too
Split userland and module SRPMS
Conditionalize whether to build the modules or the userland or both based on some passed in build options (rpm.livna.org uses "--without modules" and "--without userland")
Hardcode our assumptions based on arch somewhere, eg. if target=i586 or i686, no userland will be built, and if target=i386, no modules will be built
gets my vote.
For 4), remember that we've also got smp (and in CentOS 4, which I'd also like to support, hugemem).
#2 has some appeal, particularly since it avoids rebuilding the userland stuff for every kernel update, but it requires some careful consideration about the dependency relationship between the userland and module packages.... (I've been assuming a requires version-release kind of thing, but on reflection, that'd be *hard* and generally *not* wanted -- but then, in the cases where it *is* wanted, not possible. Gah.)
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage".
One spec file can produce packages like the following IIRC:
openafs-V-R openafs-client-V-R kernel-module-openafs-V-R.%{cleankver} openafs-devel-V-R
My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't.
Or you could make the userspace gunk in a subpackage. No reason that kernel-module-openafs can't generate both kernel-module-openafs and openafs packages.
What about archs? We probably don't want i586 and i686 userland openafs stuff, but just i386. Choices:
<insert AFS is special here>
- Just ship userland as i586 and i686 too
- Split userland and module SRPMS
- Conditionalize whether to build the modules or the userland or both based on some passed in build options (rpm.livna.org uses "--without modules" and "--without userland")
- Hardcode our assumptions based on arch somewhere, eg. if target=i586 or i686, no userland will be built, and if target=i386, no modules will be built
My openafs packages only build the userland packages if the current arch you are building for is a basearch. Conversely, it does not build a kernel module for the i386 arch.
Yes *sigh* my spec has a list of basearchs hard coded in.
This makes the most since, however it would be nice for RPM to provide basearch information rather than hard coding it.
- gets my vote.
Beleive me. This is very yucky. You really don't want to.
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage".
One spec file can produce packages like the following IIRC:
openafs-V-R openafs-client-V-R kernel-module-openafs-V-R.%{cleankver} openafs-devel-V-R
Indeed. Just give the subpackage its own Release tag.
On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage".
One spec file can produce packages like the following IIRC:
openafs-V-R openafs-client-V-R kernel-module-openafs-V-R.%{cleankver} openafs-devel-V-R
Indeed. Just give the subpackage its own Release tag.
I honestly don't care which is the base and which is the subpackage. The biggest issue I see is with arch determination, since they HAVE to be the same between base and subpackage.
The userland package should only have the userland arch (i386, sparc, ia64, ppc, x86_64), whereas the kernel-module package needs to exist for all of these arches (i386, i586, i686, ia64, ppc, ppc64, sparc, sparc64, x86_64).
I think that overcoming this obstacle may require that the two packages be built from separate SRPMS. As always, I'm open to suggestions.
~spot
On Wed, 2005-06-29 at 10:35 -0500, Tom 'spot' Callaway wrote:
On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't.
I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage".
One spec file can produce packages like the following IIRC:
openafs-V-R openafs-client-V-R kernel-module-openafs-V-R.%{cleankver} openafs-devel-V-R
Indeed. Just give the subpackage its own Release tag.
I honestly don't care which is the base and which is the subpackage. The biggest issue I see is with arch determination, since they HAVE to be the same between base and subpackage.
Not, if you separate "building the rpm" from "releasing the rpm".
Example: # rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc i386 glibc-2.3.5-10.src.rpm i686 glibc-2.3.5-10.src.rpm
Ralf
On Wed, 2005-06-29 at 18:23 +0200, Ralf Corsepius wrote:
I honestly don't care which is the base and which is the subpackage. The biggest issue I see is with arch determination, since they HAVE to be the same between base and subpackage.
Not, if you separate "building the rpm" from "releasing the rpm".
Example: # rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc i386 glibc-2.3.5-10.src.rpm i686 glibc-2.3.5-10.src.rpm
Thats a very good point, but it will certainly make conditionalizing the spec file fun. :)
I'm not opposed to that.
Example spec:
# This is defined by the buildsystem, NOT on a per package basis. #%define kver 2.6.11-1.1369_FC4 %define cleankver %(echo %{kver} | sed s,-,_,g) %define kernelonlyarches i586 i686 ppc64 sparc64 %define userspacearches i386 ppc sparc %define kernelanduserarches ia64 x86_64
Name: foo Version: 0.3.6 Release: 1 Summary: Userspace components for foo Group: System Environment/Base License: Whatever URL: http://www.example.com/foo Source0: http://www.example.com/foo/foo-%%7Bversion%7D.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: kernel-module-%{name} BuildRequires: kernel-devel-%{_target_cpu} = %{kver} ExclusiveArch: %{kernelonlyarches} %{userspacearches} %{kernelanduserarches}
%description These are userspace libraries and binaries to make the foo module usable.
%package devel Group: Development/Libraries Summary: Development headers and libraries for foo Requires: %{name} = %{version}-%{release}
%description devel This package contains the include files and static libraries for developing applications that use foo.
%package -n kernel-module-%{name} Group: System Environment/Base Version: %{version} Release: %{release}.%{cleankver} Requires: kernel-%{_target_cpu} = %{kver} Provides: kernel-module
%description -n kernel-module-%{name} This package contains the foo module compiled for kernel %{kver} on %{_target_cpu}.
%prep %setup -q
%build make %{?_smp_mflags} ...
%install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT
%clean rm -rf $RPM_BUILD_ROOT
%post -n kernel-module-%{name} [ $1 -eq 1 ] && depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || :
%postun -n kernel-module-%{name} depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || :
%ifarch %{userspacearches} %{kernelanduserarches} %files %defattr(-,root,root,0755) # docs go here %doc ... %{_bindir}/fooexec %{_libdir}/*.so.*
%files devel %defattr(-,root,root,0755) %{_includedir}/* %{_libdir}/*.a %{_libdir}/*.so %endif
%ifarch %{kernelspacearches} %{kernelanduserarches} %files -n kernel-module-%{name} %defattr(-,root,root,-) # This package should NOT have anything besides the module, to avoid file conflicts. /lib/modules/%{kver}/... %endif
%changelog * Gud Fez 74 6395 Foobly Barowitz foobly@barowitz.tld - Initial RPM release
~spot
On Wed, 2005-06-29 at 11:55 -0500, Tom 'spot' Callaway wrote:
%ifarch %{kernelspacearches} %{kernelanduserarches}
This line should be:
%ifarch %{kernelonlyarches} %{kernelanduserarches}
~spot
On Wed, 2005-06-29 at 12:00 -0500, Tom 'spot' Callaway wrote:
This line should be:
%ifarch %{kernelonlyarches} %{kernelanduserarches}
With that approach, when a new kernel is released for one of %{kernelanduserarches}, and only the kernel modules need a rebuild, the result is that both userspace and the module packages will be built anyway. And the userspace package will not have its NEVR changed compared to the previous one -> something somewhere needs to be able to just discard it, and NOT push it into the repository.
Also, note that NEVR of -debuginfo is derived from the main package. So, if the NEVR of the main package does not change between updates (eg. kernel-update-rebuild-only ones, when the module one is not the "main" package), the resulting -debuginfo packages will be screwed. More info in a semi-related bug report from the FC1 days when I was first bitten by this: https://bugzilla.redhat.com/113276
There may be ways around these, but I think it'll end up messy. Splitting the SRPMs would be a much simpler approach, and I don't think that the maintenance burden of doing that would be untolerable at all.
On Wed, 2005-06-29 at 21:09 +0300, Ville Skyttä wrote:
There may be ways around these, but I think it'll end up messy. Splitting the SRPMs would be a much simpler approach, and I don't think that the maintenance burden of doing that would be untolerable at all.
Honestly? I agree. Even if it means we end up with two copies of the full source in two SRPMS.
Unless someone is violently opposed to splitting the SRPMS as policy (and can come up with a way to resolve the unnecessary userland package bumps/rebuilds), thats what I'm inclined to adopt.
~spot
On Wed, Jun 29, 2005 at 06:55:59PM -0500, Tom 'spot' Callaway wrote:
Honestly? I agree. Even if it means we end up with two copies of the full source in two SRPMS. Unless someone is violently opposed to splitting the SRPMS as policy (and can come up with a way to resolve the unnecessary userland package bumps/rebuilds), thats what I'm inclined to adopt.
I'm fine with this or with the ifarch conditional plan -- either way has its ugliness. :)
On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
# This is defined by the buildsystem, NOT on a per package basis. #%define kver 2.6.11-1.1369_FC4
If kver isn't defined, probably the canonical specfile should have a way to either die in an explanatory way, or else guess at a default somehow.
URL: http://www.example.com/foo Source0: http://www.example.com/foo/foo-%%7Bversion%7D.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: kernel-module-%{name}
*Probably* Requires: kernel-module-%{name} = %{version}, yeah? Maybe not, but I bet in the general case these need to match.
On Wed, 2005-06-29 at 14:05 -0400, Matthew Miller wrote:
On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
# This is defined by the buildsystem, NOT on a per package basis. #%define kver 2.6.11-1.1369_FC4
If kver isn't defined, probably the canonical specfile should have a way to either die in an explanatory way, or else guess at a default somehow.
This would implement the latter, which is useful for local rebuilds for the current running kernel:
%{!?kver: %define kver %(uname -r)}
On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
%define kernelonlyarches i586 i686 ppc64 sparc64 %define userspacearches i386 ppc sparc %define kernelanduserarches ia64 x86_64
Is there a reason to not just do:
%define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64 %define userspacearches i386 ppc sparc ia64 x86_64
Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and kernel-module-hugemem-%{name} subpackages?
(Or is that kernel-smp-module, to match kernel-smp-devel?)
On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote:
Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and kernel-module-hugemem-%{name} subpackages?
(Or is that kernel-smp-module, to match kernel-smp-devel?)
None of the above; the variant is included in %{kver}, which is the output of "uname -r" for the target kernel.
On Wed, Jun 29, 2005 at 09:49:44PM +0300, Ville Skyttä wrote:
Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and kernel-module-hugemem-%{name} subpackages? (Or is that kernel-smp-module, to match kernel-smp-devel?)
None of the above; the variant is included in %{kver}, which is the output of "uname -r" for the target kernel.
Oh; duh.
In the case of openafs, that requires some more hackery to figure out if we're supposed to be giving the options for an smp build. But I suspect this *way* falls into the category of "openafs is a weird bad example case".
On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote:
In the case of openafs, that requires some more hackery to figure out if we're supposed to be giving the options for an smp build.
Doesn't the openafs build figure that out automatically from the kernel tree you're pointing it at [1]? Upstream issue?
[1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+
On Wed, Jun 29, 2005 at 10:13:27PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote:
In the case of openafs, that requires some more hackery to figure out if we're supposed to be giving the options for an smp build.
Doesn't the openafs build figure that out automatically from the kernel tree you're pointing it at [1]? Upstream issue?
[1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
OpenAFS sucks...you have to pass the build different options for UP versus SMP.
# UP first %configure --with-afs-sysname=%{sysname} --with-linux-kernel-headers=%{ksource_dir} --enable-kernel-module make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_UP=1" MPS=UP only_libafs
# then SMP %configure --with-afs-sysname=%{sysname} --with-linux-kernel-headers=%{ksource_dir_smp} --enable-kernel-module make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_SMP=1" MPS=MP only_libafs
Jack
On Wed, Jun 29, 2005 at 03:19:37PM -0400, Jack Neely wrote:
In the case of openafs, that requires some more hackery to figure out if we're supposed to be giving the options for an smp build.
Doesn't the openafs build figure that out automatically from the kernel tree you're pointing it at [1]? Upstream issue?
OpenAFS sucks...you have to pass the build different options for UP versus SMP.
Capital Letter Upstream Issue. :)
In their defense, they're trying to maintain software with kernel modules for a dozen different operating systems.
On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote:
On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
%define kernelonlyarches i586 i686 ppc64 sparc64 %define userspacearches i386 ppc sparc %define kernelanduserarches ia64 x86_64
Is there a reason to not just do:
%define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64 %define userspacearches i386 ppc sparc ia64 x86_64
Not really. :)
~spot
Spot,
I like. :-)
Jack
On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
What about archs? We probably don't want i586 and i686 userland openafs stuff, but just i386. Choices:
<insert AFS is special here>
Hm, actually, I don't know a thing about openafs, just used it as an example. s/openafs/foo/ in the above.
My openafs packages only build the userland packages if the current arch you are building for is a basearch. Conversely, it does not build a kernel module for the i386 arch.
What's a basearch, the same as in yum/rpmUtils? If x86_64 or ppc is one, does your package build modules for it?
Actually, no. I'm not going to standardize kernel module packaging _UNTIL_ at least yum is fixed.
Let me reiterate some points that I have made in the past:
Good, gets us all back on track. :-)
- I do not plan to overload the %{name} value for kernel module
packages. This means that we will NOT be shoving the kernel version in %{name}. Its ugly, it screws up bugzilla, breaks existing packaging guidelines, and is altogether wrong.
- Given that, we WILL need to put the kernel version (in some part) in
either %{version} or %{release}. Let me explain why:
I can tolerate %{release}
On SMP systems, at a bare minimum, there will be two kernels installed:
kernel-smp-2.6.12-1.1400_FC5 kernel-2.6.12-1.1400_FC5
If we do not use kernel version in either %{version} or %{release}, we'll have no way to generate two packages with unique %{name}-%{version}-%{release} values.
We have to assume that each installed kernel will want to have a matching module addon installed for it.
I originally proposed (back in March) that we put the kernel version in Release. This is a slightly revised proposal.
Name: kernel-module-openafs (where the value in the Name field is the name of the module, prepended with "kernel-module-") Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1")
So %{version} ends up having the upstream version number and the release number combined. I think this is the worst part as its confusing to the packager. Why I advocate requiring %{kver}. However, I did not propose a solution for a unique NVR for eatch kernel type (smp, xen, etc).
Release: %{kver} (Where %{kver} is the kernel we're building against) Requires: kernel-%{_target_cpu} = %{kver} BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
%{kver} gets passed by the buildsystem, for each kernel found in the branch for which that package is being built. So, for our example kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, respectively. FC4 and newer kernels have this value in the provides for "kernel-%{arch}", so it should not be too difficult for the build system to figure out the correct value for %{kver} from the target kernel package.
There is no need to use dist tags here, since %{kver} includes the dist name.
If a bugfix needs to be made to the package, then the .1 (build revision) is incremented. If a new version of the kernel driver is released, then the first part of the Version is incremented, and the build revision is reset to .1 (if it is not .1).
So, after the buildsystem does its thing, we've generated two new binary rpms:
kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm
Since no previous packages with those n-v-r's exist, yum installs them, just as it would kernels, doing the equivalent of an rpm -i action.
Now, on the system we have all four packages installed:
kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp
But wait, I've found a bug in kernel-module-openafs. Easy enough to fix, I patch it away, increment my build revision to .2, and we now have these new packages available:
kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm
But, here yum doesn't know what to do. We can't do a -i, those packages would conflict with the existing kernel-module-openafs packages. We can't do a -U, because then we'd only end up with one kernel-module-openafs package on the system. What we need yum to do is a special operation that does the following (only for kernel-module packages):
- Does any kernel-module-openafs package exist on the system with the
same %{release}?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).
I have a patch for yum that does exactly this except it keys off of the kernel requires. (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5 require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?) So in a day or two I could probably have it edited to do the above.
After this process, the system has:
kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp
Now, if someone is willing and able to write the exception case needed for yum in kernel-module-* packages, then I think we can document the remaining standard bits, duct tape the necessary logic into the buildsystem, and start doing kernel-module-* packages for FC4 and devel.
Since I already have a good bit of the code done...
Spot, the only change I would like in this is to have the build number not in %{version} but as part of %{release}. So using your example,
kernel-module-openafs-1-2.2.6.12-1.1400_FC5
Where the %{release} == build#.%{kver}
This doesn't add or subtract any complexity from the code in Yum. It does make the versioning a little easier to grok.
Reading the new mail I got as I wrote this it looks like Matthew and I agree. Cool.
Jack
~spot
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Actually, no. I'm not going to standardize kernel module packaging _UNTIL_ at least yum is fixed.
You realize how backward this is, right? 'Fixing' yum is quite hard until the kernel module packaging is standardized.
Implementing a single policy is a whole lot easier than coding to meet every possible policy.
-sv
I've taken the liberty of starting a page at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is intended to be a collection of what we have so far. Judging from what has been said to date we still don't have an effective scheme for Version and Release.
On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote:
I've taken the liberty of starting a page at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is intended to be a collection of what we have so far. Judging from what has been said to date we still don't have an effective scheme for Version and Release.
-- Ignacio Vazquez-Abrams ivazquez@ivazquez.net http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
%{version} and %{release} being what they would normally be is what we've boiled down to. Neither one contains the kernel VR. %{version} is the version of the kernel module ('1.3.84' for kernel-module-openafs) and %{release} being the build ID ('1'), per normal.
Spot, I think keying off the requires works very well.
Jack
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Wed, 2005-06-29 at 10:03 -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote:
I've taken the liberty of starting a page at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is intended to be a collection of what we have so far. Judging from what has been said to date we still don't have an effective scheme for Version and Release.
-- Ignacio Vazquez-Abrams ivazquez@ivazquez.net http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
%{version} and %{release} being what they would normally be is what we've boiled down to. Neither one contains the kernel VR. %{version} is the version of the kernel module ('1.3.84' for kernel-module-openafs) and %{release} being the build ID ('1'), per normal.
We really need a unique NVR for each package. Using kver in %{release} is the best way to accomplish this.
Otherwise, we overwrite in the repo.
~spot
On Wed, Jun 29, 2005 at 10:03:57AM -0400, Jack Neely wrote:
On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote:
I've taken the liberty of starting a page at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is intended to be a collection of what we have so far. Judging from what has been said to date we still don't have an effective scheme for Version and Release.
-- Ignacio Vazquez-Abrams ivazquez@ivazquez.net http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
%{version} and %{release} being what they would normally be is what we've boiled down to. Neither one contains the kernel VR. %{version} is the version of the kernel module ('1.3.84' for kernel-module-openafs) and %{release} being the build ID ('1'), per normal.
Spot, I think keying off the requires works very well.
Jack
Its obviously too early in the morning.
Ignacio, I must correct myself. The kernel VR should be appened to the %{release} tag for the packages.
packaging@lists.fedoraproject.org
-
Ignacio Vazquez-Abrams -
Jack Neely -
Matthew Miller -
Ralf Corsepius -
seth vidal -
Tom Callaway -
Ville Skyttä