Op 28-01-2008 om 00:41 schreef Daniel Dickinson: > Hi, > > 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. So no tag in debian/control like Installer-Impact: High 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. If I remember correct, was that workflow started when d-i could only fetch udebs from one location. I'm not aware if d-i can fetch meanwhile from other locations. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
