On Tue, 23 Mar 2010 21:19:59 +0000 Neil Williams <codehelp@debian.org> wrote: > 1. Removals in Debian are manual and it's hard to keep Emdebian in sync > with packages that have been removed from Debian. I'm working on a way > of calculating package removals. Necessarily, packages that have been > removed tend also to be uninstallable or conflicting with packages that > have been added or updated. > > 2. New packages in Debian are also manual and adding them to Emdebian > is manual too. I use edos-debcheck to assist but bug #540797 gets in > the way of an automated fix. > > 3. Testing migrations - Debian has some automation, as does Emdebian, > but Debian checks the dependencies of the packages to migrate and the > Emdebian calculation already takes a long, long time to process so I > don't add in that check. Actually those three could be a Google Summer of Code plan. Sufficiently complex, involving difficult problems of recursion and algorithm design, real issues of improving server performance under increased numbers of tests - could be an excuse to write some C code to replace the perl and abstract the problem into a mathematical model along the lines of what edos-debcheck itself performs. (It takes edos-debcheck a few seconds to calculate the dependency chain against an entire Debian package set but my current perl code takes 20 minutes to calculate the testing migration list in our reduced package set and this only gets worse as more packages are added.) Having said I'm working on these issues, actually it's a case of "thinking about the issues a bit and considering what the code should do but not actually writing any code yet", so perfect for a GoS project! -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpS4FsdXLyiS.pgp
Description: PGP signature