On 16 February 2016 at 17:27, Martin Pitt <firstname.lastname@example.org> wrote:
> Dimitri John Ledkov [2016-02-10 20:32 +0000]:
>> This would mean that the universe component will always be available
>> to get build-dependencies.
> I think that just opening up the wide pool of universe is actually
> going to make things much worse -- IMHO this should become a new
> component that sits in between main and universe, something like
> "main-build". These don't need a full MIR review, but if all of a
> sudden 1000 new packages want to enter there then maybe that *is*
> worth a second look. So archive admins can promote "obvious" stuff
> without fuss, but raise a red flag if things go really bad.
> There is a lot of breakage in universe and we regularly remove
> packages nobody cares about. If those are now suddenly 20 levels deep
> in a build dependency chain of something in main (and this is not an
> exaggeration if you look at maven, ruby, or haskell!), we effectively
> commit ourselves to having to maintain that stuff instead of the bits
> in main that we actually care about. And we all know how well that
> Dimitri John Ledkov [2016-02-10 21:22 +0000]:
>> And looking at the bottom of:
>> All of haskell and a bunch of other things are trying to enter main at
>> the moment. So it's hard to estimate things for xenial, given how much
>> is currently in-flux in it. with hundreds of things mismatched.
> That's exactly what I mean! By doing this you now get into a trap that
> your $critical_package (unity or whatnot) is FTBFS because it
> transitively build-depends on the Haskell transition that's going on,
> or the PHP 5 → 7 reorg, or possibly both. I. e. you render these
> packages unbuildable and got into a situation where you have to fix
> half of universe first.
Yes, and no. In practice we already have many "main" packages getting
entangled with "universe" for migrations, and components missmatches
(due to copies from silos).
And indeed it causes the problems that doko mentioned. E.g. a
compiler-like package in main fails to migrate because for example
things in universe are not fixed. At the same time a main-only package
builds & migrates continuously, even though it is not buildable in
The bits about haskell and php -> we must not have components
missmatches in the release pocket. It used to be that FTBFS was in a
way enforcing that, but with advent of copyting things from silos this
has regressed. It's an existing bug with our archive, which my
proposal doesn't change. But we are ought to have fixed it a long time
ago. I've now proposed a fix to britney for this:
It will prevent migrating missmatched packages (on the [Pre-]Depends
Once above is in, and current missmatches in release pocket are
cleaned-up we will be in much better state all around.
However, this complaint is nothing to do with archive-reorg, but with
the fact that we have been letting so many broken things migrate into
This reorg will not end up with e.g. haskell getting included in main,
as that generates binary dependencies and britney will prevent that
from migrating, when the above branch is merged.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel