Re: 2.6.12 upload

[Horms <horms@debian.org>]

On Wed, Jul 27, 2005 at 02:22:09PM +0200, Goswin von Brederlow wrote:
> Horms <horms@debian.org> writes:
> 
> > On Tue, Jul 26, 2005 at 06:23:05PM +0200, Goswin von Brederlow wrote:
> >> Horms <horms@debian.org> writes:
> >> 
> >> > On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> >> >> Horms <horms@debian.org> writes:
> >> >> 
> >> >> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> >> >> >> The DI kernel udebs (linux-kernel-di-<arch> source) takes the
> >> >> >> kernel-image deb, splits it up into kernel and several groups of
> >> >> >> modules and builds udebs. There is no Depends there and can't be to
> >> >> >> keep the kernel-image debs available.
> >> >> >> 
> >> >> >> 
> >> >> >> kernel-image-di-arch ---source---> linux-kernel-di
> >> >> >>                                           |
> >> >> >>                                         magic
> >> >> >>                                           |
> >> >> >>                                           \/
> >> >> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
> >> >> >>           |
> >> >> >>           \/
> >> >> >>    kernel sources
> >> >> >> 
> >> >> >> 
> >> >> >> The 'magic' part is the problem.
> >> >> >
> >> >> > I don't follow why there is a problem with linux-kernel-di 
> >> >> > depending on kernel-tree-X.Y.Z-N.
> >> >> >
> >> >> > -- 
> >> >> > Horms
> >> >> 
> >> >> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> >> >> and kernel-image packages without any regards to linux-kernel-di. They
> >> >> will become out of sync and end up without source -> GPL violation.
> >> >> 
> >> >> In the old setup kernel-source-2.6.8 will remain until removed manualy
> >> >> and linux-kernel-di has that as source.
> >> >
> >> > But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
> >> > Surely this resolves the problem some people percieve with regards
> >> > to the GPL.
> >> 
> >> No. Since linux-2.6 source means kernel-tree-x.y.(z+1)-1 will replace
> >> kernel-tree-x.y.z-n now.
> >> 
> >> You would have to provide 1 <= z <= Z, 1 <= n <= N for it to still
> >> work.
> >
> > Ok, understood. Is there a reason that the dependancy can't be on 
> > kernel-tree-x.y.x-N?
> >
> > -- 
> > Horms
> 
> Haeh?
> 
> The dependency is on the exact source used to build the binary.

We seem to be running around in circles here. If an image package
depends on kernel-tree-x.y.z-N, then kernel-source-x.y.z can be
updated and the image can still be rebuilt, verbatim.

Let me try and illustrate by example:

* kernel-source-2.6.8 version 2.6.8-1 is released
* kernel-image-2.6.8-i386 version 2.6.8-1 is released with a dependancy
  on kernel-tree-2.6.8-1
* kernel-source-2.6.8 version 2.6.8-2 is released
* kernel-image-2.6.8-i386 is not updated, but can still be rebuilt
  using kernel-source-2.6.8 version 2.6.8-1 or version 2.6.8-2

Now, if di could use the kernel-tree dependancies, then
kernel-source can be updated and the di images can still be rebuilt.

-- 
Horms