gtkhtml3 and 3.8.15 are in crypto because of a builddepends on libsoup (and its crypto dependencies). The packaging description mentions that the crypto portions are only used for testing during compile. Running otool -L on the gtkhtml library shows no links to crypto libraries.
Crypto policy says in part "As an extension of this policy, any package that Depends (or BuildDepends) on such a package must also be in crypto". Is this extension the kind for which there is never an exception? (Like: tests things using crypto libraries but doesn't implement crypto, and doesn't link to crypto libraries in its binaries.) If it is a 'no-exceptions' case, how do you feel about my creating gtkhtml3.8.15nc? nc= no crypto. I've found that if I strip the crypto dependencies from the info file and add BuildConflicts: libsoup-everything-but-shlibs, gtkhtml3.8.15-3.10.2 will build and the resulting library is drop-in usable for gnucash 2.0.2. I still have to test if gnucash builds against the nc version. I really want gnucash 2.x to be eligible for binary distribution. With the unification of finance-quote, crypt-ssleay, and libofx, it's down to gtkhtml3.8.15 keeping a really useful base gnucash 2.0.x in crypto. (direct online banking connections using aqbanking will always force the 'full' version into crypto). Dave -- David Reiser [EMAIL PROTECTED] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
