On 11 February 2016 at 11:36, Matthias Klose <doko@ubuntu.com> 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
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Regards,
Dimitri.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
