advice about splitting a package (libtiff-tools)
The libtiff package (upstream) includes one program, tiffgt, that
requires opengl. The current version of libtiff in debian installs
tiffgt's manual page but does not install tiffgt. (This is bug
219456.) I have built new libtiff packages that create tiffgt, which
seems like a reasonable program to include. I have two packaging
choices, both of which I have successfully implemented, but I wanted
some opinions on which way was better.
1. Just add the necessary libraries to Build-Depends so that tiffgt
gets built. This is the easiest solution, but it has the
disadvantage of having libtiff-tools get a bunch of extra
dependencies (X and opengl libraries) just to support one
program.
2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where
the latter contains only tiffgt and its manual page. This is
also really easy, but there's one catch: older versions of
libtiff-tools already include the manual page for tiffgt, which
means libtiff-opengl must conflict with versions of libtiff-tools
that are older than this new version. This means that someone
installing libtiff-opengl without first upgrading libtiff-tools
will have libtiff-tools REMOVED. To work around this, I could
make libtiff-opengl require libtiff-tools >= the minimum version
instead of making it conflict with the old version, but I don't
want to do this because libtiff-opengl doesn't actually depend
upon libtiff-tools.
So, should I include tiffgt in libtiff-tools and just not worry about
all the new dependencies, or should I deal with this short-lived but
annoying problem of people possibly installing libtiff-opengl without
first upgrading libtiff-tools and losing libtiff-tools as a result?
Most people will have all those libraries on their systems anyway, and
I suspect not many people running systems without X will bother with
libtiff-tools.
Thanks for any advice.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: