Mailinglist Archive: opensuse-buildservice (257 mails)

< Previous Next >
[opensuse-buildservice] Re: [RFC] Release numbers and the Kernel project
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 16 Oct 2006 10:54:32 +0200
  • Message-id: <200610161054.32403.adrian@xxxxxxx>
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@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups