Re: short-term plans for libtiff
I wonder whether I might be able to get some kind of response on my
proposal to upload a tiff with libtiff5-alt-dev. To help you make a
decision, I'm supplying the information you probably need. I'm hoping
you'll be able to give me a quick decision, or at least give me a quick
response indicating when you will be able to make a decision. I've laid
everything out here, so you should just be able to read through this.
Here's the package entry from debian/control:
------------------------------
Package: libtiff5-alt-dev
Section: libdevel
Architecture: any
Depends: ${misc:Depends}, libtiff5 (= ${binary:Version}), libtiffxx5 (= ${binary:Version}), libc6-dev | libc-dev, zlib1g-dev, libjpeg-dev, libjbig-dev, liblzma-dev
Conflicts: libtiff5-dev
Description: Tag Image File Format library (TIFF), alternative development files
This package is a temporary package designed to make it possible for
packages to use features in libtiff5, such as bigtiff, while still
having indirect dependencies on libtiff4-dev. This package will go
away after the release of wheezy. You should only use it if you have
a requirement to have both libtiff5-dev files and libtiff4-dev files
installed on your system at the same time. See README.Debian for
additional information.
------------------------------
libtiff5-dev also declares a conflict on libtiff5-alt-dev. The two
packages conflict because they both install pkg-config files for
"libtiff-4", which is what upstream calls it for 4.x. Tiff 3.x does not
provide a .pc file.
The debian/libtiff5-alt-dev.install package is identical to
debian/libtiff5-dev.install. Then I rearrange things post installation
using the following entry in my debian/rules file (I use cdbs):
------------------------------
# --- TEMPORARY -- remove when libtiff5-alt-dev is gone ---
# Also remove debian/libtiff5-alt-dev.*
# --- TEMPORARY -- remove when libtiff5-alt-dev is gone ---
# Also remove debian/libtiff5-alt-dev.*
binary-post-install/libtiff5-alt-dev::
sed -i "s,^dependency_libs=.*,dependency_libs=''," \
debian/libtiff5-alt-dev/usr/lib/*/*.la
rm -rf debian/libtiff5-alt-dev/usr/share/man
mkdir debian/libtiff5-alt-dev/usr/include/libtiff5-alt
mv debian/libtiff5-alt-dev/usr/include/tiff* \
debian/libtiff5-alt-dev/usr/include/libtiff5-alt
LDIR=$(wildcard debian/libtiff5-alt-dev/usr/lib/*); \
mkdir $$LDIR/libtiff5-alt; \
mv $$LDIR/lib* $$LDIR/libtiff5-alt; \
l1=`readlink $$LDIR/libtiff5-alt/libtiff.so`; \
l2=`readlink $$LDIR/libtiff5-alt/libtiffxx.so`; \
rm $$LDIR/libtiff5-alt/libtiff*.so; \
ln -s ../$$l1 $$LDIR/libtiff5-alt/libtiff.so; \
ln -s ../$$l2 $$LDIR/libtiff5-alt/libtiffxx.so; \
sed -i "s,\(lib\|include\)dir=\(.*\),\1dir=\2/libtiff5-alt," \
$$LDIR/pkgconfig/libtiff-4.pc; \
sed -i "s,libdir='\(.*\)',libdir='\1/libtiff5-alt'," \
$$LDIR/libtiff5-alt/*.la
------------------------------
As you can see, this is basically moving the development libraries and
header files into /usr/lib/<platform>/libtiff5-alt-dev and then updating
the .pc and .la as well as the .so link for the plain (development) .so
files accordingly.
The result of this is that pkg-config libtiff-4
--libs/--includes/--cflags will point to the alternative location. The
libtiff5-alt-dev package does not conflict with any files installed
libtiff4-dev (a.k.a. libtiff-dev), so it can be installed at the same
time as that package. It has no "Provides" relationship with any of the
other libtiff*-dev packages, so it has to be declared explicitly as a
build dependency. The only drawback that I can see is that having a
libdir entry in the .la file that isn't in the standard library path
ends up causing rpath to be used on executables or shared libraries that
link with this. However, this is actually harmless in this case because
there are not actually any runtime shared libraries installed in that
directory. Changing libdir in the .la file to point to the actual
location of the runtime library doesn't work since it causes libtool to
link with libtiff4-dev if that's installed. Anyway rpath causes lintian
errors that have to be overridden, but they will go away when
libtiff5-alt-dev disappears and packages are rebuilt with regular
libtiff-dev after it points to libtiff5-dev. When this happens, it will
require a sourceful upload of any packages that build-depend on
libtiff5-alt-dev, of course, since that package will disappear and not
be provided by any other package.
The only packages that would need to use this are packages that
explicitly want or need libtiff5 but also depend on things that use
libtiff4. The only package I know of that specifically does this is
vips, which I also maintain. The vips packages will explicitly support
bigtiff if built with libtiff5, and there are very few packages (if any)
pages in debian right now outside of libtiff-tools that understand the
bigtiff format.
Here is the README.Debian that I intend to include with the new tiff
packages:
----------------------------------------------------------------------
Note that tiff 4.x provides libtiff5 and libtiff5-dev, while tiff 3.x
provides libtiff4 and libtiff4-dev. This may seem confusing, but it
is just because the shared library versions and the software versions
don't happen to be the same, nor is there any expectation for them to
be the same.
Until the libtiff4 -> libtiff5 transition occurs after the release of
wheezy, a new temporary package called libtiff5-alt-dev is being
provided. This package installs include and library files for
libtiff5 (tiff 4.x) in an alternative location with pkg-config files
that point to it. You should only use this package if you need to
depend on libtiff5 development files while also having libtiff4-dev
installed on your system. This package will disappear when
libtiff4-dev is removed from the archive.
The most common use of libtiff5-alt-dev will be as a build dependency
for a debian package that has a direct dependency on libtiff5 (for
example, to get bigtiff support) and an indirect dependency on
libtiff4-dev. In this case, you can have your package specify
libtiff5-alt-dev instead of libtiff5-dev as a build dependency. If
your package finds the location of libtiff headers and libraries with
pkg-config, then all you will have to do when libtiff5-alt-dev
disappears is to change your build dependency to libtiff-dev, which
will then point to libtiff5-dev. For an example of a package that
does this, look at vips. Note that if you link use this package, your
executables or shared libraries will include an rpath that points
/usr/lib/<arch>/libtiff5-alt. This is harmless since no actual shared
libraries will live in that directory, but it is a side effect of
having libdir set in the libtiff.la file there, which is needed for
libtool to link with the correct -ltiff. This situation will cause
lintian errors, but the problem will go away after the libtiff
transition is complete.
-- Jay Berkenbilt <qjb@debian.org>, Thu, 24 May 2012 15:50:07 -0400
----------------------------------------------------------------------
Again, I believe this is harmless. It creates a very small number of
cases where a package will have to be changed and re-uploaded during the
transition, but there will obviously be several packages like that for
other reasons (things that explicitly depend on libtiff4-dev). I
suspect that only a very small number of packages will actually do this.
I am open to alternative ways of doing this, but without something like
this, packages that want bigtiff support and also depend on things that
use libtiff4 will have to resort to including tiff 4.x sources in their
package as some things were doing prior to the introduction of
libtiff5-dev.
I tested this by building vips packages. Vips has a ton of dependencies
including many that also depend on libtiff4-dev. The only change to the
vips packages (aside from lintian overrides) is changing the build
dependency from libtiff4-dev to libtiff5-alt-dev and changing the
corresponding dependency of the dev package. ldd shows the resulting
package to have linked with both libtiff4 and libtiff5. Bigtiff support
works as does the rest of the package.
May I proceed? If not, can you give me some explanation of what I need
to do?
--
Jay Berkenbilt <qjb@debian.org>
Reply to: