Archive Reorg Episode VII: Follow Build-Depends

Thu Feb 18 11:36:09 UTC 2016

Hi Martin,

Thanks for the thoughtful feedback.

On Tue, Feb 16, 2016 at 06:27:59PM +0100, Martin Pitt 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.

I have to disagree with this.  If these packages are only being used as
build-dependencies, I don't think there's any reason to do review a priori,
or require the archive admins to do busywork of changing archive components.
Even if there were 1000 new packages, that doesn't mean that we should spend
extra effort on paring down the dependency tree before it's proven to be a
problem.  It just doesn't buy us enough in the common case to warrant the
overhead of ongoing monitoring.

(BTW, I definitely don't think a new archive component is the right answer
here, as that has grave implications for everything from mirroring to
upgrades.  *If* we were to implement something like this, a packageset seems
more suitable - a packageset still requires a launchpad-side confirmation
and would thus be auditable, but wouldn't have a user-facing impact.)

> 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
> works..

Today, for any package that is being MIRed, we have two options for dealing
with its dependencies/build-dependencies.  We can either commit the security
team to supporting them and claim that some team is responsible for
maintaining them in the devel release; or, we can introduce a delta to the
package versus Debian in order to drop the dependency.

This proposal simply gives us a third (and default) option with respect to
build-dependencies: to postpone the decision about whether we would rather
maintain it or drop it until it actually requires maintenance.  As often as
not, agreeing to "maintain" these packages in main is a fig leaf; what we're
really saying is that we are signing off on the package because we don't
expect it to be any extra work.  But if it does actually wind up requiring
work, we're not necessarily prepared for that; so I don't see any advantage
for having such a package in main rather than universe.  The end result is
the same, it's only that in one case we get to drop the up-front paperwork
and save time for the vast majority of packages that don't actually become a
problem.

When archive admins remove packages from universe, we should be tracing
their reverse-dependencies.  If the revdep tree includes a package in main,
then we have a responsible team who will need to make the decision at that
time about how to keep their package buildable.  But the decision about how
to keep their package buildable doesn't need to be done as part of the MIR
process for every single package just for the minority of packages that will
cause problems later.

> Dimitri John Ledkov [2016-02-10 21:22 +0000]:
> > And looking at the bottom of:
> > http://people.canonical.com/~ubuntu-archive/component-mismatches.html
> > 
> > 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.

Giving developers the freedom to build-depend on packages in universe
without an MIR process doesn't mean they *have* to make ill-advised choices
about build-depends.  Unity build-depending on php would be crazy; but why
should the archive admins be trying to pre-judge such things?  The
maintainers would figure out it was crazy on their own if it started to slow
them down.  I don't think we need archive-level enforcement to handle this.

Also, php is in main and would remain there in the face of the proposed
change, so maybe not the best example ;)

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160218/99a3a3fe/attachment.pgp>