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: