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?
Shrug.)
> 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.
No.
> 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: