Re: [D-I] Preparing for update in stable

[Andreas Barth <aba@not.so.argh.org>]

* Frans Pop (aragorn@tiscali.nl) [060428 20:40]:
> On Friday 28 April 2006 11:28, Jeroen van Wolffelaar wrote:
> > If they do need to be in the Packages files too (so, multiple entries
> > in the same Packages file with the exact same package name), we need
> > some dak changes, and it's a bit risky, because dak assumes at various
> > places that the (packagename, suite, architecture) tuple is unique
> > (which then, it isn't anymore). But before exploring that possibility
> > -- is keeping those udebs in pool enough? Or would it require d-i
> > changes? Would d-i require changes if all udebs in question were in the
> > Packages files?
> 
> We're talking about kernel udebs here. For some architectures these have 
> the ABI in the package name, so for those there should be no problem, 
> you'd have two different packages with different names. For example:
> cdrom-core-modules-2.4.27-2-386-di (1.04)
> cdrom-core-modules-2.4.27-3-386-di (1.04sarge1)

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.

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


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/