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

Re: intention for tiff packages

On Sat, Jan 21, 2012 at 11:38:10 -0500, Jay Berkenbilt wrote:

> 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.
I think that's a bad plan.  There are packages in the archive right now,
including shared libraries, that build-depend on the unversioned
libtiff-dev package.  They'd pick up a dependency on libtiff5 on a
rebuild, which is not a good thing if we're not going to move the whole
archive to it.

> 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.
As I said previously, if versioned symbols don't happen (in both the old
and new versions), then the transition is unlikely to happen too.  It
was done for png and jpeg, so it's not like it'd be a first.

> 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.
If we want to accomodate those packages then one option would be to
do something similar to your plan, but make libtiff5-dev a real package
that does *not* provide libtiff-dev, and make it very, very clear that
no shared lib is allowed to use it, and that packages using it must make
sure none of the other libs they depend on can pull in libtiff4.  Which,
now that I wrote it down, sounds like a recipe for trouble because it's
going to be impossible to keep track of that stuff.


Attachment: signature.asc
Description: Digital signature

Reply to: