Re: 2.6.12 upload
On Mon, Jul 18, 2005 at 03:19:05PM +0200, Thiemo Seufer wrote:
> Andres Salomon wrote:
> > Alright folks, I think the packaging is ready to be beaten on by people.
> > So, unless anyone has any concerns/problems/etc, I'm going to assume
> > everything's a go for uploading 2.6.12.
> >
> > The current changes and state of the packaging:
> > - source package is called linux-2.6
> > - binary image packages have been renamed from kernel-image-* to
> > linux-image-*. binary header packages have been renamed from
> > kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have
> > any comments/concerns/requirements, please be sure to let us know.
> > - debian/control is generated from debian/templates/control.*.in, and
> > naming/descriptions should be consistent across the various archs.
> > - config files are generated from the pieces in debian/arch, with
> > management of configs made a lot easier via tools in trunk/scripts
> > (initconfig and split-config). I will probably tweak settings for
> > the global config a bit more; expect some FTBFS for architectures
> > until we figure out which options are safe for everyone, and which
> > options are suitable only for certain archs.
> > - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> > miscompiling things. however, if any architectures require gcc-4.0,
> > either let me know, or update svn directly.
> > - debian/README* and trunks/docs/ has information that kernel team
> > members will find useful to understand the new packaging.
> > - there are 3 patches that were in 2.6.11 that have been dropped due to
> > lack of interest; sparc, alpha, and powerpc folks should determine
> > their value, at some point.
>
> FWIW, I gave up on the common kernel package for mips/mipsel for now,
> and will build mips kernels via a linux-patch package which
> build-depends on the source .deb. The reasons which prompted me to
> do so are listed below, vaguely in order of importance.
Would you reconsider after a discussion of your points, and work together to
bring them to a satisfactory point for all instead of going your own lone way ?
A few comments on your problems, in light of the 2.6.12-5 packages and over a
month of development since you wrote this. I believe that all but mips/mipsel
are already in the main linux-2.6 package, so you are the only one having
problems with this.
> Issues of the common kernel package:
>
> General problems:
> - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
> are thrown out of the archive, anything which isn't ready until then
> will lose support.
> It is IMHO not realistic to expect the rest of the world to wait for
> some obscure subarchitecture.
Ok, this is a valid point, the current argument from Andres is that we have
one set in unstable and one in testing, and that we keep arches with problems
artificially outside of testing, so the older version remain.
This causes indeed problems with d-i, but this is more a d-i build bug than
anything else, and needs to be checked or adapted.
This whole point may need more thought maybe, but for 2.6.12 is no problem as
there is no 2.6.11 we are removing.
> - Coupling the smallest fix for a subarchitecture to a full upload of
> the whole arch any package puts pressure on the autobuilder network
> without much gain, and causes many users to download "new" kernels
> identical to the old ones because of the version bump. -> E.g.
> disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
This can and should be fixed with the so called arch-specific uploads
(-x.0.0.1 or something such), which is a mechanism supposedly documented for
this exact purpose (for example, powerpc could have rebuilt -3 in this way).
Upto recently this was not supported by the infrastructure script, but i
believe either it was fixed for the sarge packages, or it can easily be.
Not sure about the ftp-master/buildd admin side of this however. Any comment
on this are welcome.
> Implementation problems:
> - A generic header package is used, plus architecture-specific header
> packages which add some bits like configuration defines and process
> structure offsets. Architecture-specific header patches aren't taken
> into account, but are needed for patches outside include/asm-$arch.
Well, hppa and m68k already have arch-specific patches, and there is a
post-install hook for headers which allows you to install your own stuff. This
is a false problem that can easily be fixed.
> - Flavour names are assumed to be unique, this doesn't work well for
> bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
> bit kernels.
I think Andres already fixed this, but i will let him comment on this.
> - Architecture-specific patches are restricted to a single patch per
> arch/subarch, with an $arch.* naming. This means to copy an identical
> patch with different name to support mips/mipsel, it also means all
> patches which may break some other architecture have to go into a
> single file, which is ridiculous form a maintenance POV.
Valid point, which could be adapted.
I think the best idea would be to have arch/<arch>/patches instead of the
patches-arch we currently have, and the own patch/series setup inside those,
would that satisfy you ?
> - Architecture-specific patches have no series mechanism, IOW they
> aren't really updateable. Even if they had, it is not feasible to
> keep multiple 2MB mips patches around for the whole duration of the
> 2.6 kernel series.
See above.
> - The current patch system breaks easily down. If one of the patches
> has a conflict, it is neither possible to unpatch the already applied
> patches nor does a patch replay help (because the first already
> applied patch conflicts now). So it's either rm -rf or to work around
> the patch system.
This seems something more like an hindrance or wishlist than a bug,
improvement in this are welcome i would say.
> - Only -p1 patches are accepted -> no CVS diff patches, originally
> psted patches can't be used easily.
Well, a simple sed job should fix the patches :)
> - If $EDITOR leaves a ~ backup file in the series directory, the patch
> system doesn't check if the series name is valid and tries to apply
> the copy as well.
no such cruft should exist in the uploaded package, but this is indeed
something worth fixing, and should be easily enough to fix. I don't think we
saw a bug report about this from you, nor a patch, nor you fixing it yourself.
> - Same goes for the control file generation, some moved away directory
> gets searched for control.in files as well, no check for valid arch
> names or the resulting duplicate package definitions.
Also easily fixable, if not fixed already.
> - The resulting control file suggests every available bootloader for
> each image, with an [ $arch ] specifier. This is generally ugly and
> doesn't help for e.g. mipsel subarches with per-subarch bootloaders
> (colo, delo, sibyl).
Well, i am sure waldi's arch/<arch>/defines will yield a satisfying resolution
to this, i belive this is already possible, as -powerpc and -powerpc-smp
depend on mkvmlinuz, while -powerpc64 does not.
> - The shell-snippets-disguised-as-makerules generally fails to catch
> errors.
Also easily fixable if not fixed already.
SO, all in all, there has been one month of active development, and there is
only mips/mipsel left, and i believe that apart from the first point, most of
your objections are either fixed or could be easily enough, so i strongly
suggest you have a look at the current setup and integrate mips/mipsel in it,
or at least provide a new list of to-fix items you have problem with.
We should probably discuss the one linux-2.6 package only in a separate
thread, especially one cross posted to debian-boot and maybe debian-release as
they are also concerned.
Friendly,
Sven Luther
Reply to: