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