On Wed, Oct 25, 2000 at 09:24:48PM -0700, Joey Hess wrote:
> > How should these udebs be treated by testing?
> We will probably work out something where we bless a Packages file that
> points at certian udebs as being a particular release of the debian
> installer. That should then be handled by testing however testing
> handles versioned releases of the boot-floppies right now. (How does it?
> Shrug.)
boot-floppies are basically not handled at all by testing atm. All the
coordination already has to be done by Adam anyway for them to be built,
so there's nothing really left for testing to do.
> > 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
Grrr. This is, of course, all wrong. I wish I'd stop doing that.
pool/ main/
s/ source/
source (.dsc, .tar.gz, .orig.tar.gz, .diff.gz)
binaries (.deb)
ubinaries (.udeb)
dists/ stable/ main/
binary-i386/
Packages file referencing .debs
install-i386/
Packages file referencing .udebs
source/
Sources file references .dscs etc
Maybe reserving disks-* for boot-floppies and creating a new install-* for
debian-installer would be a good thing? If not, just s/install-/disks-/g.
Calling them udebs might be helpful to avoid naming conflicts in the pool.
Probably _something_ is necessary to avoid naming conflicts in the pool
at any rate, if not .udeb, then...?
> I've actually been wondering if it might be possible to put the udebs in
> binary-i386 (but not in the Packages files for any distribution), and
> then just have Packages files in disks-i386 (or whatever). This lets us
> use some features of the package pools for udebs too. James?
Does the above match this? No .debs will actually be in the binary-*
dirs when we've finished moving to pools, of course.
> > Hmmm. Am I missing something? Treating disks-* as just another
> > architecture sounds much more appealing now than it did before.
Okay, then, I think this is what'll I do when you start getting d-i to
usable. It'll mean that you won't really get to declare a "release"
of d-i except with the actual release of Debian, there'll just be a
pile of udebs that'll all work together, and be relatively bug free,
just like normal .debs. I think this is a good thing. If it turns out
more control is a good thing, we can add that to testing as we go (in the
same way I'll probably be adding to testing during the actual release).
Sounds good, anyway.
> > 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?
> The release notes should go in a regular debian package, as far as I'm
> concerned. There is no point in using a udeb unless we want to install
> the release notes onto the installer for some reason.
Wouldn't it be useful to be able to read the release notes before/while
you install?
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:
pgphYpLaeBRoR.pgp
Description: PGP signature