Re: How would you use britney for Kali and are generalization patches welcome?
On 2014-07-21 18:25, Raphael Hertzog wrote:
> Hi Nields,
>
> Thanks for your fast answers!
>
You are welcome :)
> 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... :)
>
Yeah, I have been messing a bit with this. So far I got one interesting
patch, which partly mitigates the current situation. I got a few more
experiments in the pipeline, but promises that your original data set
will be fixed with it.
>> 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.
>
Great. :)
>>> 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.
>
Indeed, I just wanted to be up front about the fact. Also note that I
suspect Britney will be de-facto frozen for (non-bug/non-crash fix)
changes during (and possibly some time before) the freeze.
>>> - 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.
>
Personally, I considered whether (part of) the "valid candidate"
selection could be moved to independent validators with a
"state"-file/dir and possibly some config options.
But I ENOTIME'd on designing that, especially because I wanted to
clean up the basic data structures first (which, short term, is also
"0-benefit")
>>> - 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?
>
Partly because your use of "etc." suggested it was not a full list, so I
wanted the full list. But also because I feel there is more this than
"just" changing the names. In their current form, their names gives
them a well-defined meaning (at least, to Debian).
* Are two "updates" suites sufficient?
- Currently you don't seem to need more than two, but if we are
generalising the terms, then this might be the time to generalise
the concept of an "updates"-suite as well.
* What are the names of the "updates" suites?
- It will be a tough sell if they "just" become "updates1" and
"updates2" (from "tpu" and "pu").
* Are there other terms/jargon you want changed (and to what)?
>>> - 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
>
Great. :)
It might have been me, who had local changes, silly me.
> 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).
>
Missing attachment(s). :)
> 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,
>
Certainly. For reference, Britney has a test suite[1]. Be sure to use
and update it diligently. :) It also contains an optional "live-data"
(submodule) test suite (mostly used for behavioural regression testing).
Note that the live-data test cases seems to average ~10 minutes each and
can sustain a 1-1.5GB of RAM during the run. I am unsure if it ever
peaks beyond that in memory.
~Niels
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git
Reply to: