Hi Nields, Thanks for your fast answers!
On Wed, 16 Jul 2014, Niels Thykier wrote: > Your problem in a nutshell: You triggered something that looks like > O(2^n) runtime in Britney. /o\ I suspected something like that... :) > Short-term options include: > * patch Britney reject on first new uninstallable Thanks for the patch, but to save time I rather opted for this: > * bootstrap from something closer to the "source" suite I'll start with jessie, and inject our forked packages and make sure we get everything to migrate at least once. > > Also I would like to know if you would be interested in patches > > that would make britney more easily reusable in other contexts > > than Debian itself. I am thinking of things like: > > /Personally/, I am generally pro this (though with comments to some of > the points below). Though keep in mind that these changes are basically > 0 benefit for Debian (short term at least). Having more users of britney will benefit to Debian in the long run so it's IMO a benefit but not a short term one. > > - allowing usage of multiple directories to define britney's unstable > > I would be willing to accept/support it if it was combined with support > for processing the regular mirror layout. Mostly, I see no point in > having this, if you still have to mash your mirror into the layout we > used some 10 years ago. > Mind you, this will possible require that some of Britney's data files > being moved else where (e.g. BugsV, Dates) OK. It would also be nice if could configure the rules for each source or at least have hints that have some knowledge of the origin of the package considered. For instance, for Kali, I would like to never consider a package from debian-testing if the same package is forked in Kali. Or I might want to impose a delay to packages updated in Kali but no delay in packages taken from debian-testing. > > - renaming Debian jargon to generic concepts: unstable -> source, testing > > -> target, tpu/pu => updates, etc. > > In general (and still personally) yes, but I am not ready to comment on > the concrete renaming of concepts. Was that due to lack of time or just that you have no idea what would be better names? > > - make it easier to disable features that are not needed (right now I have > > to create quite a few empty files, and configure delays to 0 days, etc.) > > Again, I could be interested here as well. Ubuntu have some patches for > this as well (though as I recall, we did not quite like the approach > they used, but it was quite a while since I last saw their patches). Do you remember where those patches are? Or Colin? > Speaking of which, do you have a link to your Britney VCS tree, so I can > have a look at what patches you have (or haven't) applied. I noticed > that the line numbers in your stack trace was off compared to my version! :) Weird, as I had no special patches. Anyway I pushed my git repo here: http://git.kali.org/gitweb/?p=britney2.git;a=summary git://git.kali.org/britney2.git FWIW, while I was doing some tries I produced the attached patch to implement a --skip-auto-hinter option (and another one for whitespace cleanups done automatically by vim's python-mode plugin https://github.com/klen/python-mode). I don't want to promise anything but it's good to know that you're open to merge patches to make britney more widely useful. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
