On Mon, Oct 23, 2000 at 10:35:37PM -0700, Joey Hess wrote: > I would respond to this point by point but it probably suffices to say > that we have discussed with James how the debian-installer packages can > fit into the archive, and once the new package pool stuff moves into > place James is pretty sure it will be easy to do and has committed to > doing it. Note that this isn't putting them into `main' in the usual sense (which was the sense people were talking about a while ago), but rather just changing the disks-* directories to be a little more like the binary-* directories. It might, at some point, become useful for there to be some mini-policy about these debs, or even for it to just be put in policy proper. The following's the only productive piece of this email, and followups should probably be just to -boot. How should these udebs be treated by testing? My understanding is that the new d-i archive will work essentially as follows: dists/ stable/ main/ binary-i386/ various .debs disks-i386/ various .udebs some basic boot-floppies release notes source/ source to all the .debs and .udebs Am I also correct in thinking that each udeb will be generated from a single auto-buildable .dsc? That'd be really impressive if you could pull it off. Am I at least correct in assuming each has an associated .dsc? I suspect package-pools will necessitate this. The way testing works is to pick and choose new source files and run various checks on the associated debs (like "do they match the source, or are they out of date" and "will they be installable"). The easiest way for me to handle udebs (I think) is to just to completely ignore them: so if all of a package's .debs are okay (and if there are none of them this is trivially true), then it's okay to go in testing. If any of them aren't, they're not. But this will probably cause breakages in testing's boot floppies, which I consider a very bad thing. So I guess another possibility would be to just treat the disks-* stuff as another architecture just like binary-* at the moment. Does that make sense? Will disks-* have Packages files? Will the dependencies make sense? Hmmm. Am I missing something? Treating disks-* as just another architecture sounds much more appealing now than it did before. Are there any cross-dependencies that I'd have to worry about (ie, a .deb depending on a .udeb or vice-versa, without there being a real .deb (resp. .udeb) that'd also satisfy the dependency)? I assume not. Would it be possible, do people think, to have (eg) a release-notes.udeb from which a script on ftp-master automatically extracts the release notes and dumps them somewhere useful? Ditto vmlinuz, and the boot-floppies themselves? Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark
Attachment:
pgpFV6VlN1fGp.pgp
Description: PGP signature