Re: How would you use britney for Kali and are generalization patches welcome?
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/
Reply to: