Am Sunday 15 October 2006 21:32 schrieb Andreas Gruenbacher:

On Sunday 15 October 2006 13:53, Jan Blunck wrote:

...

Therefore my proposal for fixing this issue: a buildservice package link should inherit the release number from its source package. All changes inside the linked package (additional patches, files, ...) should be added to this release number.

I would like to see a solution, which would work also without a special hack inside of the build system. 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). 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. Since this affects also the kmp module packages, I want to repeat the current state of discussion. Please correct me, if I am wrong ;) 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. 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).

I don't understand what you mean exactly: do you mean that when there are changes other than plainly linking the package, then the release number should be <linked-to-package-release-number> + 1, and if there are no changes, the package should keep the original <linked-to-package-release-number>?

I'm not sure that we want to hardwire the way how release numbers are computed for linked packages; I could imagine that we sometimes want to use the same release numbers for the linked-from and linked-to packages, and in other cases we want to keep the release numbers independent.

actually, the concept of hardwire release numbers do break the idea of having the guarantee that they get always increased in a proper way by the build system. So, I do see more problems introduced than solved by this ...

In the kernel case in particular, we need to associate each particular check-in (i.e., each set of package sources) with a unique identifier; this is sufficient so that all the packages will refer to the correct paths in /usr/src/* and /lib/modules/*. Without it, building external kernel modules would break.

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.

This unique identifier could be the release number as we do in Autobuild, or it could be some sort of source release number: The build service release numbers are of the form x.y, where x gets incremented per checkin, and y gets incremented per build. We could the x part in the kernel.

Beyond this necessary minimum requirement, it would be nice to fully synchronize the release numbers (source and build), so that all the kernel packages that "belong together" can easily be identified without having to know that the ".y" part of the release number can be ignored for this purpose. I'm not totally convinced that this is the best idea though; keeping a build number has other benefits.

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 .... -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org