On Sun, 17 Jul 2005 00:36:38 -0400, Jurij Smakov wrote: > On Sun, 17 Jul 2005, Bastian Blank wrote: > >> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote: >>> Hm, anything I'm forgetting? >> >> - The scripts dir in the linux-headers package must match the flavour. > > The problem here is that some architectures (s390, powerpc and mips) are > using two different ELF formats, depending on the options in kernel config > file. So, building different flavours for s390, for example, will produce > two different (incompatible) sets of executables in scripts/ subdir. As we > are currently including scripts/ directory only in the arch-common headers > package, that will be broken on the architectures. A simple solution: > include scripts/ subdirectory into the flavour-specific headers package. > Probably, it makes sense to do it only for architectures which actually > need that. I'll check what I can cook up.
This should be fixed in SVN; I'm just waiting for the final test to build. The scripts directory is now in each flavour's linux-headers package. > >> - The descriptions are wrong for non-i386. > > I am not too happy with how the decscription stuff turned out. I think > that the boilerplate descriptions should be generated only if the custom > descriptions are not provided, and there should be a Makefile.inc variable > controlling it. I suggest that support for custom descriptions be > restored. > >From my last svn commit: + Add some description files for flavours. Basically, for each flavour, if + 'class' is set, then in the description, "@class@ class systems" will be + described; if class is not set, then the flavour name will be used. + Ie, if there's no desc.386, then "this kernel is for 386 class systems" + will show up in the description. + + There's also @desc@ (see the s390 stuff for an example) that will be + appended to the description. + + I haven't actually implemented this yet; please fill in what you need + for your pet architecture, and I'll do it tomorrow. Pretty self-explanatory, I hope... >> - Dependencies with arch spec for one-arch packages. > > Right, the control file is full of the packages with control fields like > this: > > Architecture: powerpc > Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), > module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], > mkvmlinuz [powerpc] > > The non-powerpc dependencies will probably not break anything, but > introduce a lot of additional clutter. I understand that it's easier that > way, but having only relevant dependencies listed would be cleaner. And, > to improve readability, it would be nice to have all the control file > generation logic moved to a separate script, which may be called from the > the rules file. As I mentioned before, I prefer each arch's bootloaders to show up in this list; however, mips requires us to not do this. So, I'll redo this bit after 2.6.12-1, when we try to get mips/mipsel in. > >> - linux-headers-.*-all is no dummy package. > > As Bastian pointed out, currently this package does not build. I can > implement it and adjust the description. > I've gone ahead and removed the -all package for now; I'm still not happy w/ the name, and they're really just sugar for module build-deps anyways; certainly not crucial. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]