[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.
>> - 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.

This is not something I consider to be a major problem.  We can either
figure out a way to make descriptions overridable on a per-{sub,}arch
basis, or revert to the per-arch control.in templates; I think the value
of having them all generated from the same template file is valuable,
however.  Just looking at the number of archs that lacked ABINAMEs, or had
things hardcoded, or just skewed from convention made me think that it
would be better in the long run to force archs to all be the same wrt
package names and descriptions.  For each arch/flavour, we really only
want to override small bits of each; if s390 is really that radically
different wrt description, we can even hardcode something in debian/rules
for now that does something special for s390's variable replacement.

>> - 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.

I disagree.  I did it this way because I prefer to see exactly what
architectures are using for their boot loaders, etc.  That's just my

>> - 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'm not sure what is meant by this, but I'll look closer..

> Best regards,
> Jurij Smakov                                        jurij@wooyd.org
> Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Reply to: