On Mon, Aug 22, 2005 at 12:24:14PM +0200, Sven Luther wrote: > > 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. You can just disable the build of that images and the old packages will remain until dak is fixed to remove such sourceless packages (Okay, the headers will be not installable further). > > - 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). No, bin-NMUs are only allowed to have a updated changelog. > Not sure about the ftp-master/buildd admin side of this however. Any comment > on this are welcome. x-y.0.1 is mapped to source x-y. > > - 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. They need to be unique per debian architecture. > > - 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. Fixed. It now spits if you move the original version away to disable them. > > - 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. Yes, it does. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Attachment:
signature.asc
Description: Digital signature