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

Re: 2.6.12 upload

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.

Reply to: