Re: NMU and ./configure -> library upgrades.

[Stefan Alfredsson <stefan@alfredsson.org>]

A similar issue that bothered me when I had a dialup connection was
the constant upgrade of libraries;

1. Developer lives on the edge and usually has the latest libs installed
2. Package becomes dependant upon bleedingedge version of libs
   -- BUT it is not really needed, for example gtk1.2.1 might
   do just aswell as gtk1.2.8
3. When the user that wants an updated package and apt's it, he has
   to download the new libraries which might just be a very minor update,
   and be many times larger to download than the actual package.

One could argue about that it is good to upgrade the libs and
its hard to keep track of what new features are really used in
a lib (which is the reason to depend on a newer version of a
library) and that he who uses the unstable distribution has himself
to blame, but what about having a build-host with the libraries
from the stable distribution, and try to build as many (application)
packages as possible on that platform, ensuring that they will
have the least common dependancy, so to speak.

Has anyone else thought about this?
Anyway, now I've got cable-access and dont mind it as much...


Quoting Itai Zukerman <zukerman@math-hat.com>:
> Now it occurs to me that if I were to NMU this package (which I have
> no intention of doing!), I will be uploading a binary package
> significantly different from the one in the archive.  I imagine this
> is the case for a great many packages that rely on ./configure and
> having certain software installed (I don't expect gimp to build-depend
> on lpr!).  Is there a solution to this problem?

-- 
Stefan