On Fri, Feb 24, 2006 at 09:21:06AM +0100, Mich?le Garoche wrote: > > 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.
A byte-by-byte comparison of the headers of the old and new libgnomeprint packages finds no differences except: new things added to the *-private.h, and an added macro and perhaps one new function in the publis headers. That's a lot closer inspection than gets done when most packages get upgraded, no? But seriously, we can't require of ourselves a higher level of quality than the uptream authors. It seems unlikely that an upstream package would have gone through a whole unstable branch series then a new stable series and have serious upgrade breakage or interface incompatibilities. So if they say "it's compatible", it's been tested by them (these versions are already several months old), and we don't find any problems in some basic testing and usage, that sounds to me like it's ready to release. > >>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...). Fink has tried to coordinate a full gnome2.x suite in exp/ and fully test all its interactions before releasing it. We learned that this is often a great way to wind up never finishing or releasing it at all. The issue here is just a missing BuildDepends. Stuff like that happens all the time, and gets fixed as soon as someone on a system without [whatever package] recognizes it problem. Or when someone discovers some sepcific combination os packages that triggers some weird interaction, for example, recent issues of libgnome2 + gnome-libs. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
