On 10 Jul 2007, at 12:22, Alexander Hansen wrote: > Jean-François Mertens wrote: >> >> On 08 Jul 2007, at 07:09, Jean-François Mertens wrote: >> >>> >>> On 05 Jul 2007, at 23:22, Alexander Hansen wrote: >>> >>>> The current version of octave in 10.4/unstable has gone to a >>>> package >>>> management system of its own to regulate installation of >>>> components of >>>> the octave-forge extensions. However, it also appears to be >>>> possible to >>>> do a monolithic version. >>>> I've gone ahead and worked up a "draft"octave-forge for >>>> octave-2.9.x >>>> .info file that uses the last available monolithic octave-forge >>>> tarball >>>> (targeted toward octave-2.9.6). >>> >>> Hi Alexander, >>> >>> I've put another draft in experimental/jfmertens/main/finkinfo/sci. >>> Since it seems not clear that monolithic versions will continue to >>> be available, this one uses octave's own pkg management system >>> to build a single fink pkg from the latest bundle _ ie, targeted >>> towards >>> octave-2.9.12, the one in fink. >>> It is slow _ (layers of pkg management systems _ they eat all your >>> CPU cycles !) _, it can possibly be improved by fetching instead a >>> tarball from their cvs repositiry _ that one would have at least a >>> top-level >>> makefile; a top-level configure cache would also improve things... >>> But it seems workable, and +/- "legal" >>> >>> Jean-Francois >> >> There is still something to fix in %p/share/octave/ls-R; >> 1) to make sure (PostInstScript) it gets re-updated correctly >> 2) perl -pi -e 's,%i,%p,' >> >> JF > I tried it out (motivated by the need for octcdf + desire for a sane > install of that). > > I assume it could be modified to use the system's OpenSSL, rather than > Fink's--so that we don't have to tag it as Restrictive?
Hi Alexander, had a look at this before posting the info file. It is not immediate : 1) already deps like libdap3 are in fact openssl-dependent (here), as shown by otool, and advertise it in their .la file, so dependent pkgs inherit it: > # fgrep dependency /sw/lib/libdap.la > dependency_libs=' -L/sw/lib -L/sw/lib/system-openssl/lib /sw/lib/ > libcurl.la -lssl -lcrypto /sw/lib/libxml2.la -ldl -lz /sw/lib/ > libiconv.la -lm -lpthread' : given the order of the -L flags, the -lssl -lcrypto must come from openssl097. In fact, the -L/sw/lib is not needed at all in this line, and should be removed; such superluous flags always cause trouble. (Conceivably the .la file looks different on a system were the pkg was built in absence of openssl097, but my first guess would be that not). Probably the problem would be alleviated by adding to libdap3 NoSetLDFLAGS: true SetLIBRARY_PATH: %p/lib but this is only for the libs, one should also make quite sure the openssl097 headers are not used in the build of octave-forge.. There might be other deps in a similar situation. 2) Even when that is fixed, there would remain something to patch octave-forge, and patching that build is bit more difficult than a usual pkg :) 3) As to the crypto aspect more generally, if you look e.g. at the "communications" subdir, it is all cryptography ... So, if we were to take fink's policy seriously, the pkg should anyway go in the crypto section ... (seems to me less effort would be involved in moving the server to the Netherlands or any other sane place than to continue worrying about such things for every pkg) But you're very welcome _ I'll be "away" for a couple of weeks. Best, Jean-Francois ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
