[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

intention for tiff packages



Here's what I'd like to do with the tiff packages.  I believe this will
be relatively non-disruptive.  Technically, I don't think I *have* to
ask permission for this, but I want to do it as a courtesy to the
release team, to give you the chance to suggest a different approach or
influence the timing, and to make sure I'm picking the best approach.  I
hope you will find a few minutes to reply so I can move forward, and I
hope I won't have to wait very long.

Current state:

 * The tiff source package in unstable is version 3.9.5-2.  It includes
   binary packages libtiff4, libtiffxx0c2, libtiff4-dev, libtiff-tools,
   libtiff-opengl, and libtiff-doc.  The libtiff4-dev package "Provides"
   and "Conflicts" libtiff-dev.

 * The tiff source package in experimental is version 4.0.0~beta7-2.  It
   includes binary packages libtiff5, libtiffxx5, libtiff-dev,
   libtiff-tools, libtiff-opengl, and libtiff-doc.  The libtiff-dev
   package "Provides" libtiff5-dev (reversing the sense from the older
   package where libtiff4-dev provided libtiff-dev) and both "Conflicts"
   and "Replaces" libtiff4-dev.  This was to set the stage for an
   eventual tiff transition.

 * Some packages (not sure which ones) apparently embed tiff 4.x sources
   because they need BigTIFF support.  This is bad from many angles.

Proposed new state:

 * Upgrade the tiff package to 4.0.0-1 and upload to unstable.  No other
   changes would be made to the package.

 * Create source package tiff3 in section oldlibs at initial version
   3.9.5-3.  Have it include libtiff4, libtiffxx0c2, and libtiff4-dev,
   and still have libtiff4-dev provide libtiff-dev for now.  Drop
   libtiff-doc, libtiff-opengl, and libtiff-tools.  (The libtiff-doc
   package from 4.x includes the older documentation as well.)
   Basically this would just be a copy of the existing package minus the
   duplicated packages.

The libtiff4-dev package and tiff 3.x binary packages will stick around
but move to the new source package.  Their version numbers will continue
in sequence, so upgrades will be seamless and automatic.  Packages that
build-depend on libtiff4-dev will be unaffected.  Packages that depend
on libtiff-dev alone (if any) will have to specify libtiff4-dev or
libtiff5-dev explicitly.  This is the only area that might cause a
hiccup, but it should be minor.  (Also, the tiff3 package would have to
go through NEW, so there could be a very brief time when the libtiff4,
libtiff4-dev, and libtiffxx02 packages might be uninstallable.)
Packages that require tiff 4.x can explicitly depend on libtiff5-dev (or
on libtiff-dev | libtiff5-dev).

I believe this is a better alternative than just dropping the older
packages entirely and forcing a full transition, but I would also be
happy to do it that way if you want, though I think it will be much more
difficult.  Otherwise, I think we should wait until both versions are in
the archive and then plan a more orderly transition that could culminate
in the removal of the tiff3 source packages prior to the release of
wheezy+1.

As a reminder, there are ABI changes between libtiff4 and libtiff5, and
there are very few source API changes, and they are clearly documented.
The tiff libraries do not use versioned symbols, and there is no one
right now how has time time and inclination to tackle this.  It's
basically not going to happen.  Anyway, it's extremely unlikely that
there will be any more ABI changes in the next many years.

There are some packages out there that require features from tiff 4.x.
We can help debian be the leader of getting the world to upgrade to the
new version of the tiff packages.

Thanks.

-- 
Jay Berkenbilt <qjb@debian.org>


Reply to: