Re: New upstream releases for bluefish and docbook-xsl for Etch
On Fri, Nov 17, 2006 at 03:54:21PM +0100, Daniel Leidert wrote:
> I would like to update bluefish and docbook-xsl with it's latest
> bluefish: version in Debian is 1.0.6, but 1.0.7 was released soon after
> we released 1.0.6 to fix a few bugs. It's really just a bug-fix release:
> [upstream NEWS file]
> - Updated translations: French, Japanese.
> - Adds datarootdir to all Makefile.in to avoid warnings with autoconf 2.60
> - Fixes application/bluefish-project MIME type icon name
> - Fixes Tcl highlighting
> - Fixes a bug when trying to save a file with a new install and a file has
> never been opened or a project is not open. Closes bug #360401.
> - Fix a bug where Bluefish would crash when deleting multiple bookmarks.
> - Fix a bookmark memory leak
> - README: more complete README
> bluefish itself does not have any important reverse dependency. So any
> problem with this update?
Um, gnome-devel is an important reverse-dependency. We can't just drop
the meta-gnome2 package from etch if bluefish ends up broken, after all.
By the upstream description, this doesn't sound too bad, but I'm still
somewhat wary because this isn't a package we can just kick out if it's
broken. As long as you're agreeing to stay on top of any bugs that do
appear and get them fixed in a timely manner, I'm ok with this.
> docbook-xsl: version in Debian is 1.71.0 and the latest available
> upstream version is 1.71.1 - also a bug-fix release fixing a bug
> reported to the Debian BTS and several bugs reported only upstream. But
> the latter one misses some files in the source tarball and it does not
> contain the fix for Debian bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310895. So I was
> talking with Michael Smith, one of the upstream authors and release
> managers for docbook-xsl and he told me, that he could maybe do a new
> release after November 20th. This release would be 1.72.0, because some
> changes were made to the behaviour of docbook-xsl. But IMO and AFAIK it
> will not break any package/application depending on docbook-xsl. I would
> really like to include the latest available docbook-xsl into Etch and
> only include important bug-fixes from upstream CVS, not an older
> docbook-xsl with massive bug-fixes from upstream CVS - this is always a
> pain, because upstream is very active and some bug-fixes need a rewrite
> of parts of the stylesheets. So what is your opinion about this? Am I
> allowed to include the latest available release into Etch?
No. An "IMO" is not enough when we're talking about introducing
incompatibilities in a package as deep in the dependency chain as this one
is. We've already been dealing with a dozen or so build failures over the
past few weeks caused by regressions in various TeX-related packages, we
don't need to add to this with behavior changes in our xsl stack.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.