Re: 2.6.8 release
Andres Salomon <dilinger@voxel.net> writes:
> On Sat, 31 Jul 2004 13:52:17 +0200, Jens Schmalzing wrote:
>
>> Hi,
>>
>> Andres Salomon writes:
>>
>>> There has been some talk on IRC about what kernel to release sarge
>>> with; some people would prefer 2.6.8 (which hasn't been released
>>> yet). If we want to do that, I would suggest getting a jump on
>>> stuff now by preparing 2.6.8rc2 in svn, naming the package
>>> kernel-source-2.6.8 2.6.7+2.6.8rc2, tagging and uploading to
>>> experimental (with associated arch-specific packages uploaded as
>>> well).
>>
>> If we want to do this, we must still make sure that the pruned tarball
>> kernel-source-2.6.8-2.6.8.orig.tar.gz that gets into unstable is the
>> vanilla tarball linux-2.6.8.tar.gz minus the non-free bits that get
>> eaten by the prune script. The above suggestion runs the risk of
>> getting us stuck with 2.6.8-rc2 as .orig.tar.gz, and then we have to
>
> No; the 2.6.8-rc2 and 2.6.8 would both have their own orig.tar.gz's. We
> would initially release kernel-source-2.6.8_2.6.7+2.6.8rc2 (and associated
> arch images), w/ kernel-source-2.6.8_2.6.7+2.6.8rc2.orig.tar.gz. This
> release would go into experimental. When 2.6.8 is released, the we upload
> kernel-source-2.6.8_2.6.8 to unstable, which would have
> kernel-source-2.6.8_2.6.8.orig.tar.gz. Note that the package name has not
> changed; only the version has. This means no NEW wait; it also means the
Aren't experimental and unstable in different override files?
> orig.tar.gz may change (as it's a new upstream release). Arch-specific
> image packages (at least for i386) don't have orig.tar.gz's, so that's not
> really relevant; however,
> kernel-image-2.6.8-1-<target>_2.6.7+2.6.8-1_i386.deb in experimental would
> automatically be upgraded to
> kernel-image-2.6.8-1-<target>_2.6.8-1_i386.deb in sid. This breaks ABI
> compatibility; however, I don't think it's a problem, since packages in
> experimental are considered, well, experimental. Since the ABI SONAME
> number thingy (that's the technical name for it :) doesn't change, we're
> not faced w/ a NEW wait.
Its a collosal problem. You can never replace a kernel image without
making damn sure the new modules work with the old kernel flawlessly.
MfG
Goswin
Reply to: