Re: 2.6.12 upload
On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> Horms <horms@debian.org> writes:
>
> > On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote:
> >> Thiemo Seufer <ths@networkno.de> writes:
> >>
> >> > Andres Salomon wrote:
> >> > [snip]
> >> >> > It is IMHO not realistic to expect the rest of the world to wait for
> >> >> > some obscure subarchitecture.
> >> >>
> >> >> Who said we're going to wait for some obscure subarchitecture? We're
> >> >> going to keep working on kernels until we freeze for etch, at which point
> >> >> the subarchitectures have a limit amount of time to catch up.
> >> >
> >> > The problem is the ongoing development in unstable. It is e.g. not
> >> > possible to build debian-installer for that subarch and upload it
> >> > if its kernel isn't already/still in unstable.
> >> >
> >> >
> >> > Thiemo
> >>
> >> Actualy there are 2 problems:
> >>
> >> 1. Slow archs will keep the kernel-source from migrating to
> >> testing. That is if those archs are still testing blockers.
> >>
> >> I think this can seriously harm the amount of testing the kernel gets.
> >
> > Suelry this is a broader problem realating to buildds in general,
> > if they aren't fast enough, they need more resources. We can help
> > this to some extent by trying to cut down on the number of flavours
> > floating around, especially on slower arches. However, the kernel
> > is by no means the largest package in Debian (I believe OpenOffice.Org
> > builds in arm take a full week) and this doesn't seem to be a major
> > problem in Debian at large.
>
> No. I don't mean that m68k will take so long to compile. Well, it
> does, but it will get there in time for medium or low
> uploads. Critical uploads might stress it though. But an extra day
> delay isn't too bad.
>
> But what if the kernel FTBFS on mips? It needs to be looked into, the
> mips patch needs to be updated, tested, merged and a new source needs
> to be uploaded. If the looking into and fixing takes 3 month then that
> will be 3 month without a new kernel in etch.
Yes, that is a problematic scenario. But if such a problem occurs,
and it really is holding up the kernel for all arches, surely
some time can be found to fix patch at the time.
> >> 2. Each kernel-image-di-<arch> source needs the right kernel-image
> >> version and source for its architecture to be present in the archive
> >> to be GPL compliant.
> >>
> >> This is only a problem for the archive software to keep track
> >> of. Someone has to write code for this.
> >>
> >> The D-I build should be using only the linux-kernel-di udebs if I'm
> >> not mistaken. As long as they are available D-I should keep building.
> >>
> >>
> >> Or did I miss something and the linux-kernel-di packages will
> >> disapear into the main kernel-source package?
> >
> > Firstly, I don't agree that this is neccessary for GPL compliance
> > in any way whatsoever, however I do accept that some people believe that
> > it is. To keep those people happy, kernel-images should depend on
> > kernel-tree-X.Y.Z-N and everything works just fine - that is, the
> > kernel-image can be reproduced verbatim ecen if the kernel source
> > package increases N.
>
> You've got the wrong packages.
>
> 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
Reply to: