On Saturday 29 April 2006 11:42, Andreas Barth wrote: > As they come from the same source package, one of them would usually > still go away (and IMHO we shouldn't break the rule that if the source > package doesn't build the binary package, the binary needs to go away > as well). Of course, users won't notice this, but we still need to keep > somehow two different versions of one source package. Hmm. I thought that _was_ what you were willing to work around. > > Some other architectures - including powerpc, arm, mips(el) and the > > "speakup" kernel udebs for i386 - do not have the ABI in the package > > name. Here though, having both the old and the new in the Package > > file would not help because d-i could not distinguish between them > > anyway when downloading the udebs, so keeping the old udebs might > > result in breaking both the old _and_ the new media. > > Hm. Has that been tried? Has what exactly been tried? I don't see what could be tried here... > How bad would it be to add a code being able > to distinguish into d-i so that we can do it better during etch's > lifetime? How would you want to distinguish between two udebs with the same name? Or are you suggesting to add an extra code (some sequence number) into the source package name _and_ in udebs and to upload a new source package with every ABI change? That seems very ugly and only increases the need for NEW processing (with corresponding delays) and removals. IMO the ABI in the udebs themselves should be enough. And all architectures will get to use the ABI for Etch, as they will all move towards using the linux-2.6 source package. > Or, a totally different idea: Why do we (technically) need to > rebuild the installer at all? Could we try to avoid that need in > future? The main reason (AIUI) we want to have a new installer with new kernel udebs is that the kernel udebs are directly derived from the kernel images, so if the kernel images disappear from stable, the kernel udebs derived from it should also disappear and be replaced with new kernel udebs derived from the current kernel images. Otherwise Debian would no longer be shipping the full source for the installer. The second reason is security. Although the risk of an attack during installation is relatively small, it can't be completely excluded.
Attachment:
pgpIWmCIg_cxf.pgp
Description: PGP signature