[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting working d-i from svn including udebs

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

Attachment: signature.asc
Description: Digital signature

Reply to: