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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
