Iain Lane:
> Hey Niels,
>
> Thanks for the mail!
>
Hi Iain,
Thanks for your reply. :)
> On Sun, Dec 30, 2018 at 07:13:00PM +0000, Niels Thykier wrote:
>> Otherwise, check your britney configuration. If the path set for the
>> "TESTING" configuration points to a standard APT mirror (with a Release
>> file) you are unaffected by this mail. If it instead points to a file
>> directory with some "Packages_X" files and a "Sources" file, you are
>> using what I refer to as the "legacy package layout".
>
> In Ubuntu we use a legacy layout. Our b1 has a mode to assemble Packages
> files for us:
>
> https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/view/head:/britney#L240
>
> In short:
>
> - Concatenate main/universe/multiverse/restricted together. We have a
> b2 modification¹ to enforce some additional restrictions on these
> archive components, but at 'main' britney time we treat these the
> same. Actually the b2 config doesn't mention these components at
> all.
> - ${SERIES}-proposed is a partial suite on top of ${SERIES}, so we
> concatenate the Packages files together. (Same for ${SERIES}-updates
> for the stable releases.)
>
Indeed, that looks very much like the legacy layout. But you do not use
--control-files, which is great. :)
> Do you know if the Release file handling that b2 currently has would
> work for us?
>
There is one thing we need to to resolve and that is the partial suites.
I thought you already had a patch for that in your fork (admittedly,
solved in a more complicated way than I thought was necessary).
Assuming that code works (commits being b144470 + 8fb3c78) you should be
good to go.
It would entirely remove the need for suite_arches plus pkg_lists in
that britney script. However, you would need to:
1) convert to use the built-in handling of faux-packages and
constraints. The hard part here is that you use ${unstable-version}
a lot in FauxPackages so we might need to generate some additional
support for that in britney2 and cherry-pick it.
2) Update the config a bit (that will be the trivial bit) to use the
mirror directly and test it works.
3) Remove the legacy code and ARCHITECTURES config.
Note: AFAICT, your fork already has the relevant code support the mirror
layout including auto detection of ARCHITECTURES and COMPONENTS
configuration from the Release file.
On partial suites: I am happy to have better support for it in britney2
proper. We would need some test cases for it in britney2 or
britney2-tests and then look at how we would solve it (I though we can
do it easier than Colin Watson did - I still naively hope that it is
simply a question of "not syncing removals" automatically).
>> Request for info about your britney sources/configs/setups:
>> -------------------------------------------------
>> We would very much like an updated list of links to your britney sources
>> (e.g. forks/clones), configurations and setups. Our aim is to get a
>> better understanding of what is out there and how you use britney. If
>> you use britney to process data generated by other tools than the ones
>> in use by Debian (like dak), it might be good to mention that as well.
>> Please send this info to debian-release@lists.debian.org.
>
> b1: https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu
> b2: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu
>
> This template config is more or less up to date, but we have production
> ones that are copies of this - sometimes the arches change between
> releases, for example:
>
> https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney.conf
>
Thanks for those. :)
> As you know, we badly need to rebase on a non-ancient britney. I got a
> few commits rebased some time last year, but every single one was
> conflicting so I eventually gave up. I'll try to find time to go again,
> but this time I'll rebase *our* stuff on top of our fork point first to
> reduce down to the minimal number of commits (and submit to you whatever
> can be), which will make fewer commits to rebase but with bigger
> conflicts...
>
> Cheers,
>
Apologies; we have not been making it easy.
I know britney has seen a lot of refactoring/changes lately, which is
not helping you in the short term but it has fixed (and will soon fix a
few more) some long standing annoyances plus hopefully soon enable us to
be (partially) vendor neutral in most of britney.
Thanks,
~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature