Re: [Fink-devel] Re: [Fink-users] gimp2 configure error
On Mar 6, 2005, at 7:13 PM, Alexander Strange wrote: No, it shouldn't be building the svg plugin at all, as that should be disabled unless -svg is built. Could it be that it builds the svg plugin in anyway when it finds (one of the) components of librsvg2? That package is installed on my system because it is needed by another package. - Koen. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/graphics gimp2.info,1.16,1.17
Alexander Strange wrote: Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/graphics In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24499 Modified Files: gimp2.info Log Message: Fix freetype2 harder, allow pango1-xft2-ft219, don't depend on freetype219-shlibs This doesn't work with the current freetype packages. If you link to freetype219, you have to depend on freetype219-shlibs. [] BuildDepends: -libpng3, libjpeg, libtiff, glib2-dev, netpbm, giflib, imlib, aalib (= 1.4rc5-2), gettext-dev, gettext-bin, libiconv-dev, gtk-doc, x11-dev, (%type_raw[-noprint] = .) gimp-print-dev, libexif-dev, gtk+2-dev, libart2, libmng2, expat, fontconfig2-dev, lcms, libwmf, pango1-xft2-dev, atk1, xml-parser-pm560 | xml-parser-pm580 | xml-parser-pm581, +libpng3, libjpeg, libtiff, glib2-dev, netpbm, giflib, imlib, aalib (= 1.4rc5-2), gettext-dev, gettext-bin, libiconv-dev, gtk-doc, x11-dev, (%type_raw[-noprint] = .) gimp-print-dev, libexif-dev, gtk+2-dev, libart2, libmng2, expat, fontconfig2-dev, lcms, libwmf, pango1-xft2-dev | pango1-xft2-ft219-dev, atk1, xml-parser-pm560 | xml-parser-pm580 | xml-parser-pm581, (%type_raw[-svg] = -svg) librsvg2, (%type_raw[-svg] = -svg) audiofile, (%type_raw[-svg] = -svg) gail17-dev, @@ -28,10 +28,10 @@ (%type_raw[-svg] = -svg) libgtkhtml2, libxslt, freetype219-dev | freetype2-hinting-dev (= 2.1.9) There is no freetype219-dev package. Plus, the freetype2-hinting package will not allow gimp2-2.2.4 to run. I thought I explained this yesterday? -- Martin --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [Fink-users] gimp2 configure error
On Mar 8, 2005, at 3:29 AM, Koen van der Drift wrote: On Mar 6, 2005, at 7:13 PM, Alexander Strange wrote: No, it shouldn't be building the svg plugin at all, as that should be disabled unless -svg is built. Could it be that it builds the svg plugin in anyway when it finds (one of the) components of librsvg2? That package is installed on my system because it is needed by another package. - Koen. That is the problem; I think I've fixed it now. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/graphics gimp2.info,1.16,1.17
On Mar 8, 2005, at 4:17 AM, Martin Costabel wrote: This doesn't work with the current freetype packages. If you link to freetype219, you have to depend on freetype219-shlibs. Why does freetype219 have a different layout than freetype2-hinting-2.1.9? [] BuildDepends: -libpng3, libjpeg, libtiff, glib2-dev, netpbm, giflib, imlib, aalib (= 1.4rc5-2), gettext-dev, gettext-bin, libiconv-dev, gtk-doc, x11-dev, (%type_raw[-noprint] = .) gimp-print-dev, libexif-dev, gtk+2-dev, libart2, libmng2, expat, fontconfig2-dev, lcms, libwmf, pango1-xft2-dev, atk1, xml-parser-pm560 | xml-parser-pm580 | xml-parser-pm581, +libpng3, libjpeg, libtiff, glib2-dev, netpbm, giflib, imlib, aalib (= 1.4rc5-2), gettext-dev, gettext-bin, libiconv-dev, gtk-doc, x11-dev, (%type_raw[-noprint] = .) gimp-print-dev, libexif-dev, gtk+2-dev, libart2, libmng2, expat, fontconfig2-dev, lcms, libwmf, pango1-xft2-dev | pango1-xft2-ft219-dev, atk1, xml-parser-pm560 | xml-parser-pm580 | xml-parser-pm581, (%type_raw[-svg] = -svg) librsvg2, (%type_raw[-svg] = -svg) audiofile, (%type_raw[-svg] = -svg) gail17-dev, @@ -28,10 +28,10 @@ (%type_raw[-svg] = -svg) libgtkhtml2, libxslt, freetype219-dev | freetype2-hinting-dev (= 2.1.9) There is no freetype219-dev package. Plus, the freetype2-hinting package will not allow gimp2-2.2.4 to run. I thought I explained this yesterday? I can't find this email, but I did find your fix, which I commited. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/graphics gimp2.info,1.16,1.17
Alexander Strange wrote: On Mar 8, 2005, at 4:17 AM, Martin Costabel wrote: This doesn't work with the current freetype packages. If you link to freetype219, you have to depend on freetype219-shlibs. Why does freetype219 have a different layout than freetype2-hinting-2.1.9? There is no freetype2-hinting-2.1.9 in current CVS. If you have one, it probably comes from your exp dir. The layout of freetype219 is simplified with respect to freetype2[-hinting], because the latter needs to be upgrade-compatible to earlier versions of packages with the same name, whereas freetype219 is a new package name and doesn't need to be compatible. I also proposed to dump the -hinting variant of freetype219 (and did not commit it to CVS) due to limited usefulness. So far nobody has protested against this layout. It is really simpler to use than before. -- Martin --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote: Hi All, Peter O'Gorman wrote: | I really wish I could propose some magic that would make everyone happy in | the upgrade process, but I can not. Is package refactoring something that's planned for the future? I've hit this a couple of times before, and the response has always been don't rename/restructure packages that are in wide use (and rightly so given the current situation), but this problem is unlikely to disappear... This is a general issue with the fink system: once a package is published and other packages depend upon it, they expect it to continue to provide the same functionality forever. The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Comments? Other ideas? -- Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
On 08 Mar 2005, at 16:00, David R. Morrison wrote: The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Looks excellent, and very safe. The only alternatives I would consider are A) to simply replace the deps on gettext-bin by deps on gettext-tools : - there are extremely few pkgs that do depend (or build-depend) on gettext-bin; a quick grep for gettext in /sw/bin yields only the following candidates to check further (several or most of them are probably false positives): autoconf automake centericq gnome-blog gnomemeeting gtk-doc meld mftrace pybliographer reportbug Those can easily be checked individually, and would leave extremely few errors - The advantage I might see is that else superfluous depends tend to stay very long in the distribution. and/or B) To accelerate the migration, do step 3, then A) above _ so everybody will be forced to upgrade gettext. Jean-François --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 8, 2005, at 10:00 AM, David R. Morrison wrote: On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote: Hi All, Peter O'Gorman wrote: | I really wish I could propose some magic that would make everyone happy in | the upgrade process, but I can not. Is package refactoring something that's planned for the future? I've hit this a couple of times before, and the response has always been don't rename/restructure packages that are in wide use (and rightly so given the current situation), but this problem is unlikely to disappear... This is a general issue with the fink system: once a package is published and other packages depend upon it, they expect it to continue to provide the same functionality forever. The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Comments? Other ideas? The Best way to find the correct builddepends is to not add gettext-tools to the packages and try to build (like during the bindist). The smoothest upgrade is to add the gettext-tools as builddeps to everything that builddeps gettext-bin. Not as many things need -tools though. It's used more for processing/creating language files than for normal package building (which just copies those files). - -chris zubrzycki - - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Security Is A Series Of Well-Defined Steps... chmod -R 0 / ; and smile :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iEYEARECAAYFAkIt62YACgkQ+/mCMqKrwHDPWACgzRlB6Yy1mWDfxO8jUQKzEabS YBsAoN0IuuXbVq2YRNUiN77RR8TMW1f0 =Asn1 -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
