[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.12 upload



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



Reply to: