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

Re: Integrating the debian-installer into the archive

Anthony Towns <aj@azure.humbug.org.au> writes:

> On Mon, Oct 06, 2003 at 04:24:23PM +0200, Goswin von Brederlow wrote:
> > > It's probably a bad idea to make it a .deb.
> > The problem isn't the building of the files. That either works or
> > gives a build failure which can then be fixed. (Which would already be
> > a big advantage [to see it fail and how].)
> Uh, if you don't already have it building on your own machines, that's
> what you need to be working on. If it's alreadying building on your own
> machines, there's no big advantage in seeing how it fails on buildds.

I don't have 11 architectures. Buildds have.

It will most certainly fail on hurd but hopefully succeed on
i386, ppc, alpha, mips and mipsel.
> > The problem is how to get the build floppy images, tftp images, cdrom.iso
> > images into ftp.debian.org automatically. Encapsulating them in a deb
> > would make it automatic but noone realy likes that.
> You upload it as a bunch of byhand .tgz's with a signed .changes file.

That means that some poor ftp admin has to manually extract up to 11
tgz files and move the images into place every day as they come in and
10 buildd maintainers would have to tar and sign it every day. Thats
11 people doing a stupid job.

> > Is disks-<arch> the right name if we include the small cdrom images?
> ftp.d.o is the right place for the source files to create the cdrom
> images. The cdrom images themselves should go on cdimage.debian.org.
> Depending on what exactly is going on, it might be appropriate to have
> nothing more than the udebs on ftp.debian.org and move all the disk and
> cd images onto cdimage.d.o.

We are just talking about small boot images ranging from a floppy to a
45 MB iso. Not a full blown 12 CD set per arch.

> (A concern with the installer stuff is that its source isn't self
> contained so the .dsc and .debs can get updated, without the disk images
> being updated too, which can be bad in various ways. Moving that problem
> outside of the archive proper can give you some better ways of dealing
> with it)

As long as it works automatically and with buildds everything is fine.


Reply to: