Removing / Deprecating old packages

------------------------------------------------------------------------------

_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Re: please update Fink wxmac28 to 2.8.9

Happy New Year to all,

The build of new wxmac28 was successfully completed on
all archs: 10.4/ppc, 10.4/intel, 10.5/ppc, 10.5/intel.
I have just committed the new finkinfo to unstable.

Thank you for sending a new finkinfo to us.

Regards,
Tomoaki Okayama

At Thu, 18 Dec 2008 16:58:29 -0500,
Steve Huff wrote:
> 
> Hello!
> 
> The current stable release of wxWidgets is 2.8.9, and this version is  
> required in order to build FileZilla on the Mac.  Would you be willing  
> to update the wxmac28 Fink package to this latest release?  I am  
> currently testing an updated .info file, and it seems to be a pretty  
> straightforward replacement.  attached is my spec, which builds and  
> installs under 10.4 PPC (i'll be testing it on other platforms shortly).
> 
> thanks,
> -Steve
> 

At Sat, 27 Dec 2008 17:38:34 +0900,
Pierre-Henri Lavigne wrote:
> 
> Konbanwa,
> 
> Merry Xmas to everybody.
> 
> I continued working on some wx stuffs. Attached the updated version for
> wxgtk-python and wxmac28. Everything built fine on my Tiger Power PC. Hope
> this will help you for testing and updating dependencies.
> 
> @Asari
> 
> I'll paste some logs in the next days, I didn't succeed compiling zphoto with
> the latest gtk version :/
> 
> @Todai
> 
> Please could you tell me if the mac version rocks for you and the mac packages
> are ok ? I'm in Tokyo for a year, I can easily move to Todai tokoros if need
> be :D
> 
> @Jed
> 
> Could you tell me please if the 2.8.9 python bindings works better on 10.5,
> and then update at the same time the SF submission ticket.
> 
> Thank you all, enjoy your holidays and sayonara
> 
> --
> 
> Pierre-Henri Lavigne a.k.a. Åkeson Chihiro
> 
> Front-End Web Developer, Fink member
> 
> http://my.opera.com/Akeson_Chihiro/
> 
> ??�????? 06 11??? 2008 10:23:04 ?K Jean-François Mertens さんは???N>
> -¾^¾7¾?:
> 
> > On 06 Nov 2008, at 00:47, Pierre-Henri Lavigne wrote:
> 
> > > An other question: I worked with JF Mertens (thanks for the seamonkey
> 
> > > fix ;) to update wxgtk to the 2.8.7 version a few months ago. I've
> 
> > > just
> 
> > > read on the site that 2.8.9 was considered as "Stable". Is this a
> 
> > > primary required update regards to Fink ?
> 
> >
> 
> > Please go ahead !
> 
> > And please try at the same time to clean up and synchronise our wx
> 
> > pkgs :
> 
> > - wxgtk : None
> 
> > - wxgtk2.8 : You
> 
> > - wxgtk2.8-py : Jed Frechette
> 
> > - wxmac : ASARI Takashi
> 
> > - wxmac28 : Todai Fink Team
> 
> > - wxpython* : None
> 
> >
> 
> > Grab those belonging to None, and try to clean out the museum pieces ...
> 
> > (egrep -rI 'wx(gtk|mac|pyt)[^2]' /sw/fink/dists/unstable
> 
> > yields as only possible deps on those
> 
> > amule : ASARI Takashi
> 
> > rapidsvn : Trevor Harmon
> 
> > zphoto : ASARI Takashi
> 
> > pythoncard-py23 : None
> 
> > spe-py : None
> 
> > pysoulseek : Christian Swinehart
> 
> > Those pkgs might need some updating too
> 
> > )
> 
> >
> 
> > So for the whole thing you have basically to coordinate with
> 
> > Jed Frechette, ASARI Takashi and Trevor Harmon.
> 
> >
> 
> > Jean-Francois
> 
> 

------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Mesa versioning change

   I was considering updating the mesa-libglw package to the
new Mesa 7.2 stable release but I am running into a shared library
issue that has me a tad baffled. The Mesa 7.2 release now builds
a libGLw.1.0.dylib with libGLw.1.dylib and libGLw.dylib symlinks.
In Mesa 7.0.x this was a libGLw.1.dylib with only a libGLw.dylib
symlink. What in the devil am I supposed to do in this situation?
The libraries should be backward compatible but the shlibs package
will have a libGLw.1.0.dylib while programs that were previously
built against the libGLw from Mesa 7.0.2 will be linked to
libGLw.1.dylib (which can't be in the shlibs as a symlink
according to fink).
    Has this situation ever occured before? Any advice would
be welcome.
              Jack

------------------------------------------------------------------------------

Re: Mesa versioning change

Jack,

What's important for linking on OS X is not the filename, but rather  
the "install_name" of the shared library.  You can check the  
install_name with "otool -L foo.dylib".

Most likely, in the older version the filename of the library was  
libGLw.1.0.dylib but the install_name was libGLw.1.dylib (with a  
symlink put in place to relate the two).  Now in the simpler version,  
that intermediate step is skipped and both the filename and  
install_name are libGLw.1.dylib.  So there is no problem.

   -- Dave

P.S. In case you are curious about the reason for this, on Linux (and  
the ELF filesystem in general), there is no versioning of libraries,  
so somebody (perhaps the libtool project) invented the "extra decimal  
plus symlink" way of enforcing versioning on libraries.  For many  
years, this same method was copied over to OS X, but it was unneeded  
because OS X has true versioning of libraries.  The most recent  
versions of libtool skip that "extra decimal" step for OS X, so I'm  
guessing that what happened is that the upstream authors have updated  
their libtool.

On Dec 31, 2008, at 9:31 PM, Jack Howarth wrote:

>   I was considering updating the mesa-libglw package to the
> new Mesa 7.2 stable release but I am running into a shared library
> issue that has me a tad baffled. The Mesa 7.2 release now builds
> a libGLw.1.0.dylib with libGLw.1.dylib and libGLw.dylib symlinks.
> In Mesa 7.0.x this was a libGLw.1.dylib with only a libGLw.dylib
> symlink. What in the devil am I supposed to do in this situation?
> The libraries should be backward compatible but the shlibs package
> will have a libGLw.1.0.dylib while programs that were previously
> built against the libGLw from Mesa 7.0.2 will be linked to
> libGLw.1.dylib (which can't be in the shlibs as a symlink
> according to fink).
>    Has this situation ever occured before? Any advice would
> be welcome.
>              Jack
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fink-devel mailing list
> Fink-devel <at> lists.sourceforge.net
> http://news.gmane.org/gmane.os.apple.fink.devel

------------------------------------------------------------------------------

Re: Mesa versioning change

Fink shlibs policy allows symlinks in the shlibs splitoff:

libGlw.dylib symlink goes in the -dev splitoff
libGlw.a archive goes in the -dev splitoff

libGlw.1.dylib symlink goes in the -shlibs splitoff
libGlw.1.0.dylib goes in the -shlibs splitoff.

No compatibility problems at all.

Peter

David R. Morrison wrote:
> Jack,
> 
> What's important for linking on OS X is not the filename, but rather  
> the "install_name" of the shared library.  You can check the  
> install_name with "otool -L foo.dylib".
> 
> Most likely, in the older version the filename of the library was  
> libGLw.1.0.dylib but the install_name was libGLw.1.dylib (with a  
> symlink put in place to relate the two).  Now in the simpler version,  
> that intermediate step is skipped and both the filename and  
> install_name are libGLw.1.dylib.  So there is no problem.
> 
>    -- Dave
> 
> P.S. In case you are curious about the reason for this, on Linux (and  
> the ELF filesystem in general), there is no versioning of libraries,  
> so somebody (perhaps the libtool project) invented the "extra decimal  
> plus symlink" way of enforcing versioning on libraries.  For many  
> years, this same method was copied over to OS X, but it was unneeded  
> because OS X has true versioning of libraries.  The most recent  
> versions of libtool skip that "extra decimal" step for OS X, so I'm  
> guessing that what happened is that the upstream authors have updated  
> their libtool.
> 
> On Dec 31, 2008, at 9:31 PM, Jack Howarth wrote:
> 
>>   I was considering updating the mesa-libglw package to the
>> new Mesa 7.2 stable release but I am running into a shared library
>> issue that has me a tad baffled. The Mesa 7.2 release now builds
>> a libGLw.1.0.dylib with libGLw.1.dylib and libGLw.dylib symlinks.
>> In Mesa 7.0.x this was a libGLw.1.dylib with only a libGLw.dylib
>> symlink. What in the devil am I supposed to do in this situation?
>> The libraries should be backward compatible but the shlibs package
>> will have a libGLw.1.0.dylib while programs that were previously
>> built against the libGLw from Mesa 7.0.2 will be linked to
>> libGLw.1.dylib (which can't be in the shlibs as a symlink
>> according to fink).
>>    Has this situation ever occured before? Any advice would
>> be welcome.
>>              Jack

--

-- 
Peter O'Gorman
http://pogma.com

------------------------------------------------------------------------------

Re: Dependency of imagemagick

Hello,

I renewed finkinfo for imagemagick and imagemagick-nox, and attached.
If they look good, I would like to commit them to 10.4/unstable.
The differences from the ones in unstable are as follows:

[imagemagick.info]
* SplitOff files that depend on gnome-related packages;
  only three files: svg.a, svg.la, and svg.so.
  See also gimp2 and gnuplot, which excellently divide
  packages into two: gnome-dependent and gnome-independent.

[imagemagick-nox.info]
* openexr depends on x11. Deleted.
* Sync with imagemagick.info.

Thanks,
Tomoaki Okayama

At Sun, 25 May 2008 02:47:20 +0900,
Tomoaki Okayama wrote:
> 
> Hello,
> 
> About a month ago, I requested SplitOff or --without-rsvg in
> imagemagick.info.
> 
> In the present finkinfo, many gnome-related packages must be installed
> for only a few files,
> i.e. lib/ImageMagick-%v/modules-Q16/coders/svg.{a,la,so}.
> It may be frustrating for non-gnome users.
> 
> How were my suggestions? Or, are there any ideas for that?
> 
> I renewed patches for suggestion (1), and attached.
> * 10.4_imagemagick.splitoff.diff (for 10.4 HEAD)
> * pango_imagemagick.splitoff.diff (for 10.4 pangocairo)
> 
> 
> Thanks,
> Tomoaki Okayama
> 
> At Tue, 29 Apr 2008 03:06:07 +0900,
> Tomoaki Okayama wrote:
> > 
> > Hello,
> > 
> > Since Feb. (or Mar. ?), lots of dependency packages have been added
> > to imagemagick. The packages seem to be needed for --with-rsvg option,
> > but I think the dependency is unwelcome for non-gnome users.
> > I have two suggestions.
> > 
> > (1) Splitoff files which depend on gnome-related packages.
> >     I attach sample patches for it.
> > * imagemagick_head.diff
> >   - openexr depends on x11. Deleted for -nox. (sync with -nox package)
> >   - Correct a typo in ConfigureParams. (sync with -nox package)
> >   - Splitoff files for rsvg.
> > * imagemagick_pangocairo.diff
> >   - openexr depends on x11. Deleted for -nox. (sync with -nox package)
> >   - Missing BuildDepends: dbus-dev, glitz.
> >   - Correct a typo in ConfigureParams. (sync with -nox package)
> >   - Splitoff files for rsvg.
> > 
> > (2) --without-rsvg. Delete gnome-related packages from dependency.
> >     This way is sure and simple. (no sample patches here)
> > 
> > 
> > How does that sound?
> > 
> > Thanks,
> > Tomoaki Okayama
> > 

------------------------------------------------------------------------------

_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Re: Mesa versioning change

David R. Morrison wrote:
[]
> Most likely, in the older version the filename of the library was  
> libGLw.1.0.dylib but the install_name was libGLw.1.dylib (with a  
> symlink put in place to relate the two).  Now in the simpler version,  
> that intermediate step is skipped and both the filename and  
> install_name are libGLw.1.dylib.  So there is no problem.

Dave, not that it matters, but I think you got it backwards: In the old 
version, there was only one libGLw.1.dylib, with filename and 
install_name coinciding. In the new version, they use the more 
complicated system, namely an implementation file libGLw.1.0.dylib with 
a symlink at the install_name.

Incidentally, the package mesa-shlibs (from graphics/mesa.info) has had 
this system already for quite some time, because the maintainer 
introduced a patch file for their ersatz libtool "mklib", doing the 
following

-        LINKNAME="lib${LIBNAME}.${LIBSUFFIX}"
-        LIBNAME="lib${LIBNAME}.${MAJOR}.${LIBSUFFIX}"
+        LINKNAME="lib${LIBNAME}.${MAJOR}.${LIBSUFFIX}"
+        LINKNAME2="lib${LIBNAME}.${LIBSUFFIX}"
+        LIBNAME="lib${LIBNAME}.${MAJOR}.${MINOR}.${LIBSUFFIX}"

plus the corresponding symlink game.

He was led to doing this by akh and jfm, see the tracker
<https://sourceforge.net/tracker2/?func=detail&aid=1611970&group_id=17203&atid=414256>
Apparently, upstream is doing the same thing now, too.

Anyway, I agree that there is no problem.

--

-- 
Martin

------------------------------------------------------------------------------

Re: Dependency of imagemagick

On Sat, Jan 03, 2009 at 06:00:46PM +0900, Tomoaki Okayama wrote:
> Hello,
> 
> I renewed finkinfo for imagemagick and imagemagick-nox, and attached.
> If they look good, I would like to commit them to 10.4/unstable.
> The differences from the ones in unstable are as follows:
> 
> [imagemagick.info]
> * SplitOff files that depend on gnome-related packages;
>   only three files: svg.a, svg.la, and svg.so.
>   See also gimp2 and gnuplot, which excellently divide
>   packages into two: gnome-dependent and gnome-independent.
> 
> [imagemagick-nox.info]
> * openexr depends on x11. Deleted.
> * Sync with imagemagick.info.
> 
> 
> Thanks,
> Tomoaki Okayama

Thanks for doing this work. I too would like to see the imagemagick
BuildDepends and Depends a little lighter :)

I have a few comments:

1)
libdjvulibre15-shlibs, which has a BuildDepends on qt3, is dependency
of imagemagick-nox. This has the unfortunate side-effect of requiring
X11 and all of qt3 to build imagemagick-nox. You may want to consider
removing djvulibre in the -nox version too.

2)
Why are imagemagick-nox.info and imagemagick.info two separate files?
This seems to be the case for the current fink release too. Isn't the
point of the %type stuff to make this unnecessary?

3)
Another approach to making imagemagick-nox lighter would be to remove
the dependencies on X11 from openexr and libdjvulibre. This is what I've
done in my own private fink package repository. See here:
http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/libdjvulibre15-shlibs.info
http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/openexr.info
http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/openexr.patch

---

James

------------------------------------------------------------------------------

_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Re: Dependency of imagemagick

Thanks for comments. For your comments 1), actually,
you (James) and I opened the similar discussions
in this mailing list last year:

http://thread.gmane.org/gmane.os.macosx.fink.devel/16300
http://thread.gmane.org/gmane.os.macosx.fink.devel/16734

8 months ago and 5 months ago... 

I just followed original packaging way basically, to be
simple and easily accepted by the maintainer (drm).

The comment 2) does not have an effect on users, so I feel
it's a matter of preference of the maintainer.

As for the comment 3), I would leave it to the maintainers.

To be specific, the present situation is:
 - libdjvulibre15-shlibs
   BuildDepends on x11-dev, but not Depends on x11-shlibs.
 - openexr
   BuildDepends on x11-dev, AND ALSO Depends on x11-shlibs.

So, the shortest way is to remove openexr from Depends of
imagemagick-nox, which is my patch. But in James's approach,
both libdjvulibre15-shlibs and openexr don't have dependency
on x11 anymore. I prefer James's approach rather than mine.
(This is my own personal feeling, and I would like to leave it
to the maintainers to judge it.)

Thanks,
Tomoaki Okayama

At Sat, 3 Jan 2009 23:47:49 +1100,
James Bunton wrote:
> 
> On Sat, Jan 03, 2009 at 06:00:46PM +0900, Tomoaki Okayama wrote:
> > Hello,
> > 
> > I renewed finkinfo for imagemagick and imagemagick-nox, and attached.
> > If they look good, I would like to commit them to 10.4/unstable.
> > The differences from the ones in unstable are as follows:
> > 
> > [imagemagick.info]
> > * SplitOff files that depend on gnome-related packages;
> >   only three files: svg.a, svg.la, and svg.so.
> >   See also gimp2 and gnuplot, which excellently divide
> >   packages into two: gnome-dependent and gnome-independent.
> > 
> > [imagemagick-nox.info]
> > * openexr depends on x11. Deleted.
> > * Sync with imagemagick.info.
> > 
> > 
> > Thanks,
> > Tomoaki Okayama
> 
> Thanks for doing this work. I too would like to see the imagemagick
> BuildDepends and Depends a little lighter :)
> 
> I have a few comments:
> 
> 1)
> libdjvulibre15-shlibs, which has a BuildDepends on qt3, is dependency
> of imagemagick-nox. This has the unfortunate side-effect of requiring
> X11 and all of qt3 to build imagemagick-nox. You may want to consider
> removing djvulibre in the -nox version too.
> 
> 2)
> Why are imagemagick-nox.info and imagemagick.info two separate files?
> This seems to be the case for the current fink release too. Isn't the
> point of the %type stuff to make this unnecessary?
> 
> 3)
> Another approach to making imagemagick-nox lighter would be to remove
> the dependencies on X11 from openexr and libdjvulibre. This is what I've
> done in my own private fink package repository. See here:
> http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/libdjvulibre15-shlibs.info
> http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/openexr.info
> http://delx.net.au/hg/finkinfos/raw-file/d0af189cd42a/main/finkinfo/openexr.patch
> 
> ---
> 
> James
> 

------------------------------------------------------------------------------

10.6 support in unstable?

  Now that fink cvs supports cleanly bootstrapping under the
10.6 seeds. is it okay to modify packages in the unstable
branch to be compatible as well? Specifically, I noticed that
libiconv needs the same changes as used in the older fink cvs
version of libiconv...

--- libiconv.info	2009-01-03 14:36:20.000000000 -0500
+++ libiconv.info.new	2009-01-02 20:08:30.000000000 -0500
@@ -41,6 +41,10 @@
 #! /bin/sh -ex
 PATH=/bin:/sbin:/usr/bin:/usr/sbin
 export PATH
+# Make sure that we get the compiler wrapper on [redacted]
+case `uname -r` in
+10.*) PATH=%p/var/lib/fink/path-prefix-10.6:$PATH ;;
+esac
 cd %b/../gperf-3.0.3
 ./configure --prefix=%p
 make

We also need to create system-openssl-dev-10.6.info package in
unstable/main/finkinfo/libs with the following differences fro
the current system-openssl-dev.info...

--- system-openssl-dev.info	2007-01-25 16:37:38.000000000 -0500
+++ system-openssl-dev-10.6.info	2009-01-02 20:16:51.000000000 -0500
@@ -1,8 +1,9 @@
 Package: system-openssl-dev
-Version: 0.9.7
-Revision: 6
+Version: 0.9.8
+Revision: 1
 BuildDependsOnly: true
-Depends: macosx (>= 10.3.0-1), macosx (<< 10.6.0-1)
+Depends: macosx (>= 10.6.0-1)
+Distribution: 10.6
 Type: nosource
 CompileScript: echo "nothing to be done"
 InstallScript: <<

Or do we plan on creating a new branch for this. I suspect the changes
are going to be minimal and mostly related to the use of gcc 4.2.1 as
the default compiler so a new branch is probably overkill.
         Jack

------------------------------------------------------------------------------