Thursday, 18 February 2016

Re: Archive Reorg Episode VII: Follow Build-Depends

On 12 February 2016 at 04:29, Steve Langasek <[email protected]> wrote:
> Hi Matthias,
> On Thu, Feb 11, 2016 at 12:36:27PM +0100, Matthias Klose wrote:
>> On 10.02.2016 21:32, Dimitri John Ledkov wrote:
>> >This does not abolish the MIR process. If a hard binary dependency is
>> >gained (e.g. shared linking), the binary and source package still must
>> >go through MIR process and be published in main.
>> So an existing app package gains a new (universe) dependency on libfoo-dev.
>> Builds fine, maybe migrates, and then image builds fail because of the
>> libfoo1 component mismatch. Now you can either pre-promote the libfoo, or
>> re-upload app without the dependency (if that works).
> There is a third option here, which I discussed with Colin and Adam and that
> (I think) we agree is workable: enable inclusion of universe in the image
> builds during development, turning this off only once we are in the final
> freeze for release.

This is de-railing the discussion a bit. This proposal is about
Build-Dependency vector only, and doesn't imply any other changes to
e.g. how we build images and with which components.

To get this change in smoothly we have now identified that:
* germinate needs to be fixed to include "built-using" into seeds
(because it's ~= static linking, and hence "Depends" relationship)
* britney should finally stop being silly and should not consider
components missmatched [Pre-]Depends for migration

The above two points are bug-fixes to the current bugs in our current
infrastructure. Which have a proposed implementation on launchpad.

Enabling "no-follow-build-depends", will reduce number of packages in
main, simplifying archive management. Less packages, in the segregated
component, implies less unwinding and package (hair) splitting
exercises we do to keep main-only going.

The total amount of breakage in the archive will stay the same (worst
case) or becomes less (due to more packages being in sync and in
universe). This distro building work is a zero sum game, and all
components are still part of Ubuntu. I am only proposing to adjust the
centre line. I am not moving the goal posts or increasing the field

I don't see convincing arguments, w.r.t. how total breakage in ubuntu
magically grows in size, with reduction of main/universe ratio whilst
keeping the overall total number of packages the same. Am I missing

A broken haskell in Ubuntu, is a broken haskell in Ubuntu with or
without it being a build-dep of a main package. And it totally holds
up migration of main libfoo1 -> libfoo2, thanks to a 3rd party source
& binary package that builds libfooX-gch haskell bindings in universe.



ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: