Daniel Dickinson wrote: > This failed with a fatal error saying that there were modules in more > than one udeb. On this list I was told that this was a kernel version > problem that was fixed, but if the rc2 tag is to mean getting a working > d-i rc2 then the packages need to match what was used with rc2, which is > obviously not the case since the rc2 cds work but the subversion > checkout and full build does not.
A d-i release does not, unfortunatly, imply a freeze or branching of the entire debian repository. Debian packages outside d-i can and do change after a release, which will then break building d-i from that tag. That's reasonable, since the point of the tag is to mark what we released, not track a continually working version of the installer. > I'm rather frustrated because d-i doesn't seem to have coherent way of > making sure one gets a working source base (d-i+udebs) to build a cd > with Yes it does, this is why d-i releases include a consistent set of udebs in the debian archive. > *and* if one tries to use a d-i from installer-i386 and udebs from > the standard testing pool, one frequently ends up with d-i/kernel > mismatches (this was what I was trying at first). This has really only been a problem in the case of the current kernel ABI clusterfuck. > I'm more than a little concerned by the fact that a checkout of rc2 does > not get one a working d-i. That is, I thought, the purpose of a tagged > 'release'. A non-working working branch I can live with; that happens, > but when something that is supposed to be a working snapshot doesn't I'd > call that a major bug, and unless someone gives me a good reason not to, > I'll probably file a bug against d-i for this. You're confusing the purposes of a tag and a branch. -- see shy jo
signature.asc
Description: Digital signature
