On Tue, Oct 01, 2013 at 01:04:31AM +0100, Phil Wyett wrote: > -------- Forwarded Message -------- > > From: Phil Wyett <[email protected]> > > Reply-to: [email protected] > > To: [email protected] > > Subject: Bug 1223199 - Unnecessary deps on packages that lock in > > things like Mir when not wanted. > > Date: Wed, 25 Sep 2013 14:42:37 +0100 > > > > Dear Technical Board, > > > > I a have a concern regarding deps being added to certain packages that > > are not really needed. My specific concern is the adding of Mir related > > dev packages to Mesa packages. Please could you look at the following > > bug. > > > > https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1223199
The Mesa packaging in Ubuntu enables the Mir EGL display, and as a result this dependency is unsurprising to me: it seems likely that it's required for reverse-dependencies to behave properly. The dependencies of -dev packages typically reflect the configure options found in their source packages. In general it is standard practice in both Debian and Ubuntu to configure packages with all reasonable and non-conflicting options enabled, in order to maximise the usefulness of the pre-built binaries we supply. (I recall that there used to be a general statement about this in the Debian Policy Manual many years ago, although I can't find it just now.) On occasion it is necessary to run separate build passes with different feature sets, but this is expensive in various ways and has never been the default practice: we only do this when there is no reasonable alternative. In this case, libegl1-mesa-dev only pulls in the Mir client libraries, for a total .deb size of around 270KiB plus a few generic odds and ends like libboost-system1.53.0 and libprotobuf7. Their presence has no effect on the host system's behaviour and doesn't enable the Mir compositor itself. Regardless of whether this was Mir or something entirely different, this isn't something I would consider it appropriate to split into a separate package; leaving aside emotional arguments about Mir, I can see no strictly rational reason to avoid this dependency. A package split without good reason would contribute further to bloating the Packages file, which has incremental costs all over the place. Furthermore, this is only a dependency from a -dev package, and therefore it seems unlikely that it would pull even this relatively modest set of library packages into any images. I don't see how this has an effect on other flavours or derivatives; it should principally affect package builds, which should be performed in clean chroots anyway. If it does affect other flavours or derivatives, please provide specific technical details, rather than fairly general comments about "bloat" and "pollution"; when bringing a dispute to a body such as the Technical Board it will help your case if you try to avoid polemic language. At this point I see no cause for concern; I am confident that the analysis above is objective enough that I would not see a cause for concern if this were a change introduced by somebody outside Canonical, nor if I did not work for Canonical. I'm willing to look at it again if shown further technical argument. > > I am also concerned with many bugs these days are getting marked as they > > are with no justification or explanation. I agree that it was not particularly helpful to mark the bug as "Won't Fix" without explanation, and I think that practice should generally be deprecated. You seem to have escalated to the Technical Board rather rapidly without first trying to find common ground on the bug report, so I infer (I may be wrong) that perhaps there is some history of disagreement between you and Timo; even so, at least a copied-and-pasted explanation of the status change would have been usual. CCing Timo to suggest this for the future. Thanks, -- Colin Watson [[email protected]] -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
