On Tue, Oct 01, 2013 at 01:04:31AM +0100, Phil Wyett wrote:
> Forwarded Message
> > From: Phil Wyett
> > Reply-to: one.u...@gmail.com
> > To: technical-board@lists.ubuntu.com
> > 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 [cjwat...@ubuntu.com]
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
