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

Re: busybox in main

Anthony Towns wrote:
> 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.

There already is, although it is very spare (dos/modules.txt in
debian-installer cvs). Only certian dpkg features can be used in udebs.

> 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?

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?

> 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

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?

> 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.

Yep. The source all goes in main/source or whatever it is called in
package pools, wherever the source for a normal debian package goes.
Some of these sources will also generate normal debs, some not.

> 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.

Yes, this sounds about right.

> 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?

Yes it will, yes they will.

> 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?

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.

see shy jo

Reply to: