Mailinglist Archive: opensuse-buildservice (257 mails)

< Previous Next >
[opensuse-buildservice] Re: [RFC] Release numbers and the Kernel project
  • From: Jan Blunck <jblunck@xxxxxxx>
  • Date: Mon, 16 Oct 2006 14:45:47 +0200
  • Message-id: <20061016124547.GC4212@xxxxxxxxxxx>
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.


> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups