On Fri, 26 Mar 2010 10:51:43 +0100 Raphael Hertzog <hertzog@debian.org> wrote: > one of our biggest problems is dealing with transitions because they tend > to get interdependant and it's thus very difficult to move packages from > sid to testing. Also many transitions are badly managed by the maintainers > who are responsible for them, some even tend to consider that once they > have uploaded the package to unstable, the rest will be done > automatically. Wouldn't a simpler method be to identify uploads that inadvertently impair an ongoing transition and bump that one upload to experimental or simply tell the DD not to upload to unstable? i.e. instead of an unknown number of concurrent overlays, a finite number of diverted / blocked uploads. Maybe extending dput functionality to check a file on a central server that lists the ongoing transitions and blocking the upload in the first place? The query would only require a wget - providing the file doesn't get too long, that could work. The file could list the packages involved and dput could scan the debc output to check that none of the declared dependencies match any of the packages in the list if the upload is targeted at unstable. I did a form of that for Emdebian Crush (emrecent) which used edos-debcheck to see if the upload was going to break the repository prior to making the upload. I'll need to revise that fairly soon to cope with the current experiments with Crush. What process is used to obtain the list of packages is irrelevant - as long as a list can be accessed and dput learns how to parse that (possibly using other tools like dcmd, debc and similar). Once that version of dput is in unstable, the problem would be significantly reduced. > It would be nice to solve those problems. I have a proposal and in order > to not make it needlessly complicated I leave out many of the details, Can we try simpler approaches that can be explained in detail first? > they will have to be fleshed out later if we agree that it's something > that might be doable and should be tried (at that point starting a DEP > would make sense to get approvals from all concerned teams because it > requires far-reaching changes as you will see). I can't see that changes to dput would require that level of work. What would need discussion would be management of the list file but there is already a list file - what is missing is a parser that can step in PRIOR to the upload being made. i.e. on my box, not ftp-master. (Yes, I have ended up in a situation where such a helper could have been very useful with xf86-input-tslib during a change of maintainer.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpSVpe_9AZAk.pgp
Description: PGP signature