On Mon, Jan 28, 2008 at 09:38:11AM +0100, Geert Stappers wrote: > Op 28-01-2008 om 00:41 schreef Daniel Dickinson: > > I've got a project I've been working on in fits and starts that I'd > > like to use d-i for. I'm working on a utility system that allows > > restore/rescue/repair/modification of a linux system (the restore is to > > be a local or networked restore of systems backed up using amanda) and > > the backup/imaging of linux/windows/mac systems. I've decided I want > > to switch to doing this using d-i (by submitting patches to package > > maintainers that will create udebs), but I want to make sure that, > > assuming the maintainers are willing to add the patches, that the new > > udebs won't cause problems for d-i proper. > > > > I'm hoping that the udebs don't mean anything to d-i unless the d-i > > build scripts pull them in as specifically directed and therefore don't > > impact on d-i unless you want them to. > > What I understand from the current way of handling udebs, > is that all udebs have the same priority.
This is not true. There are most certainly different categories of udebs, and a number of things including some control fields alter the effect of a udeb on the installer. > The protect d-i from unwanted changes due upload of packages > containing an udeb, are _all_ packages with an udeb blocked by the > ftp-masters. After an 'Okay' from the d-i team are those packages > allowed to go into the archive. This is in order to avoid mistakes, not because udebs all have the same "priority". -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
