On 11 February 2016 at 11:36, Matthias Klose <[email protected]> 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
It has been long recognized that components-missmatched packages should not be considered for migration. And we have this problem already when things are copied from devirt PPA builds into Ubuntu. I've now proposed a branch to britney to extend the generated excuse "unsatisfying Depends" to not consider components missmatched things as good enough. The merge proposal is here: https://code.launchpad.net/~xnox/britney/deps-components/+merge/286511 Case in point currently maas is a valid candidate, despite having a main package depending on a universe one, as far as above code generates: maas (1.9.0+bzr4533-0ubuntu1 to 1.10.0+bzr4578-0ubuntu2) Maintainer: Ubuntu Developers 7 days old Valid candidate vs maas (1.9.0+bzr4533-0ubuntu1 to 1.10.0+bzr4578-0ubuntu2) Maintainer: Ubuntu Developers 0 days old python3-maas-provisioningserver/amd64 unsatisfiable Depends: python3-distro-info Not considered With above fix, the rest becomes a smaller issue. E.g. "Recommends" still would "sneak" past britney, and would affect seeds/images that follow-recommends. To solve that, imho, components missmatches report should be updated to generate hints file for britney to utilize. The rest of consequences become a non-issue, with above britney fix alone. > libfoo1 component mismatch. Now you can either pre-promote the libfoo, or > re-upload app without the dependency (if that works). This probably will > lead to more pre-promotions, and looking at the current back-log of security > related MIRs the time between build and promotion will increase, making it > probably harder to revert such a change. > > I'm a bit worried that we'll then have to chase people to subscribe teams to > the new packages, write the MIR, ... We'll save some time by not processing > B-D only MIRs, but I think for the remaining MIRs we'll have to spend more > time. > > We unfortunately already have some kind of "dput and forget" attitude with > packages staying in -proposed. This change maybe will foster an > "pre-approve and forget" attitude. > > Matthias > > > -- > ubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Regards, Dimitri. -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
