[Fink-devel] openssl woes
Out openssl package is currently at 0.9.6g. However, both 0.9.6h and 0.9.7 are out for some time now. Naturally I decided to skip directly to 0.9.7. This posed some problems, since the openssl package used to hardcode 0.9.6 into the .dylib filename, and also used 0.9.6 in the compatibility version. For comparision, the normal openssl build also hardcodes the full version into th filename, but uses 0.9 as the compat version. Apple's openssl has 0.9 in the file name and 0.9 as compat version. Due to this, I assumed it should be binary compatible. However, after long testing and some neat tricks to get a smooth update possible (I believed), I had to finally conclude that openssl 0.9.7 is *NOT* binary compatible! First of, openssh refuses to work with 0.9.7 when linked against 0.9.6: OpenSSL version mismatch. Built against 90607f, you have 90700f (this is a manual check performed by all ssh* tools). Secondly, wget-ssl crashed: dyld: wget Undefined symbols: wget undefined reference to _OpenSSL_add_all_algorithms expected to be defined in /sw/lib/libcrypto.0.9.6.dylib Trace/BPT trap The crash is not a surprise of course as they removed an API. I really have to wonder about the compatibity version choice of the openssl team, but I guess maybe they are not aware of its meaning or something, I probably should contact them. Anyway: it seems openssl is source compatible at least (wget-ssl rebuild fine against openssl 0.9.7. So this leads me to the following clean update strategy, which has potential pitfalls but might otherwise be suitable for other packages, too: 1) All packages that currently depends on openssl-shlibs should remove that dependency - Dave's shlib code should add it automatically anyway (right, Dave?) 2) Optionally: I release a new revision of openssl (0.9.6h) 3) I release 0.9.7 of openssl - however, it won't have openssl-shlibs anymore. Rather, it has openssl097-shlibs (or somesuch). It will be installed parallel to openssl-shlibs. Packges that uses the old version work fine, anything newly compiled will automatically depend on openssl097-shlibs (since openssl-dev will symlink to files from that) 4) If they make 0.9.8 and it is binary compatible, I only have to rename the shlibs splitoff again The only thing i am not sure about is how well (if at all?) our current shlibs code deals with the compatibility field information. I hardly have looked at the relevant code at all, but will change that ASAP. In the meantime, any feedback on this idea is most welcome. Max --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] openssl woes
Well, Max, I like your strategy and I agree it would be a great application of the shlibs project. However, this part of the shlibs project isn't implemented yet! I have to write the code and integrate it into Fink, and I haven't had time to do that. However, even without the shlibs code this can still be done. You just have to update all of the packages which depend on openssl-shlibs to depend on the new openssl97-shlibs instead (with a new version). We'll have to keep openssl-shlibs around as a backward-compatibility library for a while, but anybody who newly builds things will have them linked to the correct library. -- Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gtkhtml vs. gtkhtml1.1
Max Horn [EMAIL PROTECTED] wrote: At 17:52 Uhr -0500 29.01.2003, Alexander Hansen wrote: On Wed, 2003-01-29 at 17:46, Max Horn wrote: At 17:12 Uhr -0500 29.01.2003, Alexander Hansen wrote: A future issue for concern (after libpng vs. libpng3) is gtkhtml vs. gtkhtml1.1 . A lot of the users have GNOME, and gnome-core-shlibs depends on gtkhtml, as does gnucash (the two examples I actually have installed). However, evolution-1.2 depends on gtkhtml1.1-shlibs . This leads to a failed update-all because gtkhtml can't be removed in favor of gtkhtml-shlibs. Hu? both should coexist just fine, no? Sorry--caffeine in bloodstream failing. I meant gtkhtml can't be removed in favor of gtkhtml1.1 No worries :-) one of the problems is/was (didn't check if it is still the case) that gnome-core-shlibs depends on gtkhtml, which clearly is not necessary. [snip] The gtkhtml package itself contains binaries (a config script, I believe); there are also -dev and -shlibs splitoffs. Should the binaries be BuildDependsOnly? Or should we just set them up so that gtkhtml and gtkhtml1.1 can replace each other freely? I'm not sure what the right strategy is here... -- Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] openssl woes
On Donnerstag, Jänner 30, 2003, at 02:17 Uhr, Max Horn wrote: snip First of, openssh refuses to work with 0.9.7 when linked against 0.9.6: OpenSSL version mismatch. Built against 90607f, you have 90700f (this is a manual check performed by all ssh* tools). This is indeed a manual check performed on all platforms. Usually you should recompile openssh whenever you update the openssl libraries. Secondly, wget-ssl crashed: dyld: wget Undefined symbols: wget undefined reference to _OpenSSL_add_all_algorithms expected to be defined in /sw/lib/libcrypto.0.9.6.dylib Trace/BPT trap The crash is not a surprise of course as they removed an API. This also happens on FreeBSD and Linux, actually that is as you said not a surprise due tot he API changes. I really have to wonder about the compatibity version choice of the openssl team, but I guess maybe they are not aware of its meaning or something, I probably should contact them. I would doubt, that they know much about openssl and I think it is a good thing to contact them to get some changes you might make upstream. snip -d - we may race and we may run, but we can not undo what has been done. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] GNOME2 is coming - test needed.
Hi fink developers, I think GNOME2 packages are almost ready for release. Upgrading from GNOME1 to GNOME2 is an irreversible process, so I'm planning that request developers test them first, then if no critical problem found, put them into unstable tree (hopefully in next week). What kind of problem I think *critical* is, 1. Cannot install bundle-gnome-2.x at all. 2. Core applications like gnome-session and gnome-panel does not work. Especially for gnome-session, it contains configuration conversion programs from debian and not tested well. If you interested in testing, please follow instructions below: 1. Backup your GNOME configurations (~/.gnome* ~/.gconf*) 2. Add packages in experimental/msek/gnome2 in Fink's CVS 3. Install GNOME2 packages (installing bundle-gnome is convenient) 4. If you'd like to test configuration conversion, remove ~/.gnome2*. 5. Launch gnome-session. First time you launch gnome-session, you will be asked whether to convert GNOME1's configuration to GNOME2's. Any suggestions are welcomed. --- Masanori Sekino mailto:[EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] gdk-pixbuf
Hi! I have project which depends on 'gdk-pixbuf'. However gdk-pixbuf currently have ton of dependencies on GNOME stuff. I've been told that it could be compiled w/o GNOME support (if it does not find one during configure). What would be right approach to resolve this? Currently user have to install dosen of packages to satisfy gdk-pixbuf dependencies. Compilation of these packages take 4+ hours and results take 800Mb of disk space. I was thinking about making 'gdk-pixbuf-nognome' package and setting in my project conditional dependency from either 'gdk-pixbuf' or 'gdk-pixbuf-nognome'. Would it be right way of doing it? Sincerely, Vadim -- La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever. (Antoine de Saint-Exupery) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] /sw?
On Tuesday, January 28, 2003, at 01:43 PM, Alexander Hansen wrote: For an install from source, the answer is yes. Thanks! -- La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever. (Antoine de Saint-Exupery) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] libpng list
Would it be helpful for me to come up with a list of remaining packages that use libpng, sorted by maintainer? -- Alexander K. Hansen Associate Research Scientist, Columbia University visiting MIT Plasma Science and Fusion Center Levitated Dipole Experiment 175 Albany Street, NW17-219 Cambridge, MA 02139-4213 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: GNOME1 dependency cleanup
On Thursday, January 30, 2003, at 09:03 AM, Masanori Sekino wrote: I started cleaning of gnome1 package's dependency including gdk-pixbuf, gtkhtml, gnome-core. But, still, even if you will minimize dependencies there will be some. What I am talking about is about having version of gtk-pixbuf which does not require GNOME at all. It is possible? Vadim -- La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever. (Antoine de Saint-Exupery) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libpng list
I think actually it is packages that use imlib that we need to be more concerned about, than libpng. Any package using both imlib and libpng should be updated to libpng3, and also should have a versioned dependency on the latest imlib from unstable. -- Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libpng list
On Thursday, January 30, 2003, at 02:28 PM, David R. Morrison wrote: I think actually it is packages that use imlib that we need to be more concerned about, than libpng. Any package using both imlib and libpng should be updated to libpng3, and also should have a versioned dependency on the latest imlib from unstable. This is not currently true, as evidenced by the update-all issue that's ending up with kdelibs3 trying to build against libpng. It's like what we discussed on #fink yesterday, where because of ordering issues, it will install libpng3, build something, install libpng, build something, and then build kdelibs3 but never put libpng3 back first, because it's already installed as far as fink knows. The proper fix is to have fink handle reinstalling packages multiple times as needed, but in the meantime, changing all libpng-using programs to use libpng3 is really the only other way around it I think. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libpng list
Sure, but I think there are really two things going on. 1) If you have an old imlib and are building a package which links libpng3, there is no way you can ever build it correctly. 2) If you've updated imlib, then once in a while, due to a bug in fink, you'll have a problem with libpng vs. libpng3. You'll have the same problem with any other pair of packages which are designed for BuildDepends and which might replace each other in the build process. Now, problem #2 can be addressed in the particular case of KDE by making sure that anything KDE depends on, even indirectly, has been properly upgraded to libpng3. However, problem #2 cannot be addressed in general without modifying fink. That is why I was suggesting that we focus on problem #1. -- Dave --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Fwd: gimp-1.2.3-10
Begin forwarded message: From: brad allison [EMAIL PROTECTED] Date: Wed Jan 29, 2003 11:06:06 PM US/Eastern To: Alexander Strange [EMAIL PROTECTED] Subject: Re: gimp-1.2.3-10 Reply-To: [EMAIL PROTECTED] On Wed, 29 Jan 2003, Alexander Strange wrote: On Wednesday, January 29, 2003, at 09:33 PM, brad allison wrote: Not sure if you got this I got a bounced message: I got it. That bit looks normal... the only thing I can think of would be doing 'fink remove gimp;sudo apt-get update;sudo apt-get install gimp' to get the precompiled version. That make it worse. Now I only have xcf (gimp) as a file format. [jackals-Computer:/sw/src] jackal# history 1 23:02 fink remove gimp 2 23:02 rm -rf /sw/etc/gimp/1.2/ 3 23:03 rm -rf /sw/etc/gimp/ 4 23:03 fink remove gimp 5 23:03 apt-get update 6 23:03 apt-get install gimp 7 23:04 history bash-2.05a$ gimp Gdk-WARNING **: locale not supported by C library /sw/bin/gimp-real: Can't open '/sw/etc/gimp/1.2/gimprc' for reading. /usr/local/lib/gimp/1.2/plug-ins/bmp executable not found /usr/local/lib/gimp/1.2/plug-ins/dbbrowser executable not found /usr/local/lib/gimp/1.2/plug-ins/faxg3 executable not found /usr/local/lib/gimp/1.2/plug-ins/fits executable not found /usr/local/lib/gimp/1.2/plug-ins/flame executable not found /usr/local/lib/gimp/1.2/plug-ins/fp executable not found /usr/local/lib/gimp/1.2/plug-ins/FractalExplorer executable not found /usr/local/lib/gimp/1.2/plug-ins/gap_filter executable not found /usr/local/lib/gimp/1.2/plug-ins/gap_frontends executable not found /usr/local/lib/gimp/1.2/plug-ins/gap_navigator_dialog executable not found /usr/local/lib/gimp/1.2/plug-ins/gap_plugins executable not found /usr/local/lib/gimp/1.2/plug-ins/gdyntext executable not found /usr/local/lib/gimp/1.2/plug-ins/gfig executable not found /usr/local/lib/gimp/1.2/plug-ins/gflare executable not found /usr/local/lib/gimp/1.2/plug-ins/gfli executable not found /usr/local/lib/gimp/1.2/plug-ins/ifscompose executable not found /usr/local/lib/gimp/1.2/plug-ins/imagemap executable not found /usr/local/lib/gimp/1.2/plug-ins/Lighting executable not found /usr/local/lib/gimp/1.2/plug-ins/MapObject executable not found /usr/local/lib/gimp/1.2/plug-ins/maze executable not found /usr/local/lib/gimp/1.2/plug-ins/mosaic executable not found /usr/local/lib/gimp/1.2/plug-ins/pagecurl executable not found /usr/local/lib/gimp/1.2/plug-ins/print executable not found /usr/local/lib/gimp/1.2/plug-ins/rcm executable not found /usr/local/lib/gimp/1.2/plug-ins/sel2path executable not found /usr/local/lib/gimp/1.2/plug-ins/sgi executable not found /usr/local/lib/gimp/1.2/plug-ins/webbrowser executable not found -- Brad Allison [EMAIL PROTECTED] http://jackal.webhop.org AIM:jackal242 This is way beyond my ken... and my barbie, and all my action figures. - The Host --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problems with lyx-1.2.2-1
Hi, Thanks for the quick fix. However, there is a problem with the MD5 checksum: $ md5sum lyx-1.2.3.tar.gz 3a423e65f647bd0a8f9401dd43e5d912 lyx-1.2.3.tar.gz while in the .info file the last digit is missing: lyx-1.2.3-1.info:Source-MD5: 3a423e65f647bd0a8f9401dd43e5d91 Thanks and cheers, Remi On Thursday, January 30, 2003, at 12:04 PM, Sylvain Cuaz wrote: Le jeudi, 30 jan 2003, à 01:08 Europe/Paris, Remi Mommsen a écrit : Are you aware of this problem? It might hose the full system. I think this version should be removed from the fink unstable tree unless you patched the fink version. lyx-1.2.3-1 is in unstable -- zauc - I haven't lost my mind - it's backed up on my disk somewhere. * Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of California, Irvine URL:http://cern.ch/mommsen c/o SLAC voice:++1 (650) 926-3595 2575 Sand Hill Road #35 mobile:++1 (650) 387-1402 Menlo Park, CA 94025, US fax:++1 (650) 926-8522 * --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Where is search.h
Why is search.h missing from darwin??? Where can I find it to run twalk?? If you do a man twalk the man page for the missing functions comes up -- tsearch, tfind, tdelete, and twalk are all listed as being available on that machine. The man page also says that file search.h is the header for these functions. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dierk Polzin mailto:[EMAIL PROTECTED]608-334-3574 cell - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] CLI usb-serial communication
Anybody has any idea how I can use my Keyspan serial adapter from the terminal? I ported a dive computer download utility (eontools - http://www.streit.cc/dive/index.html) and I intend to make a fink package of it (my first contribution) but I cannot seem to make it talk to my Keyspan adapter... Initially, there was no /var/lock folder so I created one (is that OK?)... Now, I get this error: Info: Establish lock file /var/lock/LCK..tty.USA9QW12P1.1 Info: Open device /dev/tty.USA9QW12P1.1 Can't open /dev/tty.USA9QW12P1.1 as input. Info: Set RTS to high Info: Close and unlink lock file /var/lock/LCK..tty.USA9QW12P1.1 I did install the latest drivers from Keyspan. The /dev/tty.USA9QW12P1.1 folder only appears when the Keyspan adapter is plugged in. I tried eontools on linux (ydl 2.3 with a custom kernel having built-in support for Keyspan adapters) and it worked. I'm not that familiar with darwin's way to communicate with tty devices... Any help would be greatly appreciated. I contacted the author and got some valid suggestions. He does not know darwin too much either. Étienne --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libpng list
At 14:44 Uhr -0500 30.01.2003, David R. Morrison wrote: Sure, but I think there are really two things going on. 1) If you have an old imlib and are building a package which links libpng3, there is no way you can ever build it correctly. Could somebody explain to me why exactly this is a problem? Does either imlib or libpng use flat_namespace or what? Or does imlib expose libpng structures in its API, thus causing inconsistencies? In the first case, it might be possible to fix this (subissue) by using two level namespaces, no? 2) If you've updated imlib, then once in a while, due to a bug in fink, you'll have a problem with libpng vs. libpng3. You'll have the same problem with any other pair of packages which are designed for BuildDepends and which might replace each other in the build process. Now, problem #2 can be addressed in the particular case of KDE by making sure that anything KDE depends on, even indirectly, has been properly upgraded to libpng3. However, problem #2 cannot be addressed in general without modifying fink. Yup. Am going to write a big mail on the dependency issues plans on how to do it all better Cheers, Max --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] openssl woes
At 8:27 Uhr -0500 30.01.2003, David R. Morrison wrote: Well, Max, I like your strategy and I agree it would be a great application of the shlibs project. However, this part of the shlibs project isn't implemented yet! I have to write the code and integrate it into Fink, and I haven't had time to do that. However, even without the shlibs code this can still be done. You just have to update all of the packages which depend on openssl-shlibs to depend on the new openssl97-shlibs instead (with a new version). We'll have to keep openssl-shlibs around as a backward-compatibility library for a while, but anybody who newly builds things will have them linked to the correct library. Yup. In my local tests, this seems to work well enough. I used the name openssl097-shlibs, does that sound reasonable? In fact, I think we don't even have to revision up the packages when making the transition from openssl-shlibs to openssl097-shlibs: packages built against the old one will continue to work fine, and new ones will be fine, too. Still, while I'd like this (much less work, and users aren't forced to rebuild their packages for nothing), it of course poses a problem due to the mismatch between stable and unstable: should users not have unstable *before* stable in their tree list (I am only refering to users who have unstabled enabled anyway), they would get into a bad state. Hence, we have to revision up anyway... hm. I guess the best thing is if I do that for all the involved packages, as it should be done at the same time as the new openssl gets checked in to avoid any issues. Max --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Where is search.h
At 16:02 Uhr -0600 30.01.2003, Dierk Polzin wrote: Why is search.h missing from darwin??? Where can I find it to run twalk?? You can't. If you do a man twalk the man page for the missing functions comes up -- tsearch, tfind, tdelete, and twalk are all listed as being available on that machine. But it isn't... The man page also says that file search.h is the header for these functions. When going from 10.0 to 10.1, Apple copied a lot of FreeBSD man pages, even some for things that don't actually exist on OS X. I guess somebody should file a bug report to get them to remove these man pages. Max --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] X11 docs again
Alexander Hansen wrote: Have all of the wrinkles been ironed out of the Apple X11 patch script yet, so that I can add a recommendation to the docs? I think the discussion of the install_name bug has been too much on the optimistic side. There had been some anecdotal evidence that the bug leads to build crashes here and now and not only maybe sometime in the future, and I have now seen one with my own eyes: mkdir .libs gcc -Wall -g -O2 -o allwidgets allwidgets.o -L/usr/X11R6/lib -lX11 -lXt -lXpm -lXext -lXmu -L/sw/lib -lXaw3d ../Mowitz/.libs/libMowitz.a -lXaw3d -lXpm -lXmu -lXext -lXt -lX11 -lSM -lICE -lm ld: ../Mowitz/.libs/libMowitz.a(MwSlider.o) illegal reference to symbol: _XmuCvtStringToOrientation defined in indirectly referenced dynamic library /usr/X11R6/lib/libXmu.6.dylib Note that -lXmu is there on the command line, but libXmu.6.dylib is nevertheless considered as indirectly referenced. It is referenced by one of the other libraries (maybe libXaw3d) that was built against a non-Apple version of X11. This crash goes away after Ben's install_name_fix script is run. So maybe the wording ...bug in the install name of the libraries that can cause some software to build incorrectly is too friendly. This one doesn't build incorrectly, it doesn't build at all. -- Martin --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] packages w/gtkhtml dependency
On Thursday, January 30, 2003, at 07:04 AM, Alexander Hansen wrote: There actually weren't that many, as it turns out. I'll list them by maintainer (note that some of these have dependencies on gtkhtml-dev and gtkhtml-shlibs): If it depends on dev/shlibs, there is no problem. So leave me out of this, thanks, my shlibdeps are fine. :) -Ben --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] On dependency engines
Hi folks, in the recent months, the problems with Fink's dependency engine (and dpkg's, and the way they interact) have become more and more apparent. Various problems are basically impossible to overcome with the current design, hence it seems we need a new full fledged dependency engine. For some time, I hoped we might be able to just reuse the apt engine (and the hope is still not completely gone), but as far as I can tell it can't cope with build time only dependencies (but there is the possibility to work around that, see below). If somebody is interested to look into this (that means you have to know C++, and ideally also the apt sources, or are willing to work into it), feel free to contact me. So, for now, instead of charging ahead and trying to write a new dependency engine from scratch or trying to retrofit an existing one, I went to try to write down what our needs are. Then based on this, I started to develop ideas on how to realize these needs in actual code. I try to present all my ideas and findings in this email. That includes a list of problematic cases the engine needs to handle, as well as fundamental problems, and problems that are also affecting our current system. It'll be a long email, and maybe I should put it on a web page later, too. Basic needs and issues == First off: the engine needs to deal with 4 basic types of dependency: * build conflicts * build dependencies * install conflicts * install dependencies Note that the current Depends field in fink in fact represent both a build time *and* a install time dependency; in a future fink package manager release, we will hence add new fields InstallDepends and InstallConflicts (names subject to change); this will increase the flexibility w/o adding any complexity. Due to the way fink works, it's hard to use dpkg's engine properly; e.g. fink knows it'll install all requirements for a package, but dpkg will not know that unless we install them all at the same time. There are more many scenarios where install/remove fails because fink knows more than dpkg. The only way to overcome this is to use --force-depends at least for some operations. But if we do that, we *have* to handle all dependency issues manually (be it with a complete new engine or with an existing engine, it doesn't matter). Right now fink gets off cheap as it relies on the dpkg engine to remove conflicting packages automatically, or to refuse to remove a package which is still needed. If we override this, we have to do it ourselves, increasing the complexity. Another trouble area are build time dependencies, and build time in general. Right now, fink installs build time dependencies if needed, but doesn't remove them later (which might or might not be the right approach, you can argue either way). We don't handle build conflicts at all. Also, there issues when users run multiple fink's at once (I do that frequently - no need to interrupt KDE building if I just want to quickly install figlet). Right now, this can easily lead to screw up. Just imagine openssh is building and the user removes the openssl package. Ouch, either the build fails, or gets messed because the openssh build now starts using Apple's openssl - just imagine if the version of openssl differ, then half of openssh is linked against openssl 0.9.7, the other against 0.9.6 - ouch). dpkg doesn't (and can't) handle build time dependencies at all. Fink should do that, but right now it does a very poor job at it. apt only handles them in a very limited way (for the apt-get source command), not sufficient for our needs. Ideas Solutions = I developed various ideas on how to tackle the problems above and other problems I encountered while researching this. Note that I am still not finished yet with all this (one of the reason for me to finally write this down was to get my thoughts ordered, it's easy to get lost :-). And basically, this assumes we use write own engine... Note: when I say deps (=dependencies) in the following, I usually also mean conflicts, which are also a kind of (anti)dependencies. You can view the net of packages as a graph, the packages are nodes, the (anti)dependencies are directed edges. It's actually a bit more complicated, a package can consist of many version (PkgVersion in fink), and a dependency can specify version ranges. But the idea should be clear. First, I tried to split down the problems in small units. This makes reasoning easier. For example, some of the problems we used to have in the (limited) fink dep code was caused by the fact that the Depends field actually has a blurred meaning and is *not* the same as the dpkg Depends - because it also covers build time. Realizing this and getting it straight helped a lot. Continuing this, the difference between build install time deps. Fink can either install or build or build install a package. So it's natural to break
[Fink-devel] node exists problems, again..
I'm getting: % fink update-all sudo /sw/bin/fink update-all Information about 2246 packages read in 8 seconds. Failed: Internal error: node for libungif already exists I am running current fink head. I think we squashed this error before, so perhaps it has something to do with the recent modifications to the dep loop. -Ben --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
