On Thu, Feb 11, 2016 at 12:36:27PM +0100, Matthias Klose wrote:
> 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). 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.
Maybe we can teach Britney to not migrate the packages to release pocket if
they are uninstallable within their component?
This way almost nothing will change — just like now such packages will be stuck
in proposed (the only difference is that they will build there).
> 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.
But on the other hand we'll have less MIRs for the build-dep-only stuff, which
is quite common (i.e. the JS minifiers or documentation generators).
> 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.
I think most of the packages stuck in proposed are auto-synced from Debian
(I really hope that Ubuntu developers who upload their packages specifically
to Ubuntu do care about the migration of them). In this case there is almost
nothing we can do to improve that situation anyway… (maybe advertising the
excuses page a bit more so that more people look at it?)
In any case, I'm all for Dimitri's proposed change as it will allow us to get
rid of lots of Debian delta and also stop doing strange tricks like one we did
for jQuery to make it build.
--
Dmitry Shachnev
