Re: [Fink-devel] libgnomeprint2.2-2.12.1-1001

[Michèle Garoche]

Le 24 févr. 2006 à 09:08, Daniel Macks a écrit :

On Fri, Feb 24, 2006 at 08:39:00AM +0100, Mich?le Garoche wrote:

Le 24 f?vr. 2006 ? 06:26, Daniel Johnson a ?crit :

Anyway, the brand new libgnomeprint2.2-2.12.1-1001 package requires
a BuildDepends on bison. It fails to build with the system's
version. I assume the same is also true in the other trees.

What's the correct procedure for these things? If a package has a
real maintainer I'll email them, obviously. But for a package like
this, should I just go ahead and make the change? What's the best
way to be useful? Aside from assuming the role of fink-gnome-core
of course. ;-)

From my experience with gnome:

1 - libgnomeprintui2 should be at an equivalent version number

libgnomeprintui uses libgnomeprint, not the other way around. But
regardless, libgnomeprintui was also upgraded.

That's what I exprimed, maybe lost in translation :-)

2 - it has to be checked that all packages that uses lignomeprint2.2
not only compile, but effectively work with the new version:
conglomerate, eog, evince, gal199, gal2.4, gedit, ggv, glade2,
gnumeric, gpdf, gthumb, gtksourceview, libgnomedb, librsvg2-mozilla,
librsvg2, gtk-sharp-monodoc, gtk-sharp, gtk-sharp2, gtksourceview-
sharp, gretl

I tested that several applications that use it work: binaries compiled
against the old versions runs fine when libs are upgraded, recompiling
against new versions gave no errors, and the newly-compiled binaries
run fine. The 2.10.x and 2.12.x series of the libs claim to be
forward- and backward-compatible, with no change to any of the lib
versioning values.

From experience, the claiming are not always exact.

Maybe better put it in your experimental tree, announce it on the
devel list, then all people can test it (I can make it for
conglomerate, evince, gedit, ggv, glade2, gtksourceview, libgnomedb,
in 10.- 4 stable (then it's likely it works also in 10.4-
transitional, for 10.3; Daniel Macks can test them) which I use
either directly or within my own packages.

Too late...it's already released:)

Well, and what happened when it does not compile, as Daniel reported it??? (I have not tested it already, but hopefully we are not cycling again in a non operating gnome system for a year or so. Not to be defeatist, but sigh...).

Cheers,
Michèle
<http://micmacfr.homeunix.org>

36C471DED4B09EEB30A0281F2608DB2FE6F9E147.gpgkey
Description: Binary data