On Mon, Oct 16, Adrian Schröter wrote:
I would like to see a solution, which would work also without a special hack inside of the build system.
Dito.
The problem is currently caused by the fact that the retrigger of a source link does not work yet within the build service. This means, kernel-default does not yet triggered, when update kernel-source. It could be that this particular problem disappears by accident when this is fixed (since all packages do always get triggered and the release number get increased when changing the source. However, there is not guarantee that this will always work).
No, at the moment a check-in to kernel-source triggers the rebuild of kernel-default, kernel-debug and kernel-xen and all the linked packages in other projects as well.
For some rational behind this, usually you have the version number to tell, if a package got significant changes and is still compatible. This is different for the kernel. However, every release number change does already make it complete incompatible. I do not want to discuss this now, but we need to keep it in mind when we speak about this situation.
So you think that a package is still "compatible" just because the version number is the same? The buildservice shouldn't be that "clever". If somebody checked in new sources all dependent packages should be rebuild.
The kmp modules build could check against which kernel version+release they are building against (means, they do not use the version+release from their own spec file). This could be done via a "rpm -q kernel-source" call during the build.
At the moment I use 'rpm -q kernel-dummy' to be more close to the original suse kernel.
Pro: * This works also outside of any specific build system. * You can update the drivers and updated versions get also a higher release number. Contra: * you can not see anymore if all kmp packages do fit for the kernel via the version+release number. (but this information could be exported in a different way).
Hmm, I don't get the point here.
right, but IMHO you can find these pathes during the build also without to use the version/release number from the kernel flavor or kmp module spec file.
Well, than you can't install 2.6.18-1.8 and 2.6.18-2.8 in parallel. They have different sources and so they have different binaries ...
We can ignore the .y part without any problem. However, you still have a problem when you hardwire the release numbers for the case, when you only edit a kernel flavour package (kernel-default for example). Currently this problem got hidden of the fact that also in this case all packages get rebuilded. But imaging what happens when this does change. You would get a newer package with the same version and release number ....
You don't want to modify a single kernel flavour. Otherwise you get a kernel-default without an appropriate kernel-source package. All the patches, all the changes should go into kernel-source and therefore trigger the rebuild of all kernel flavours. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org