[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fink-users
Subject:    Re: [Fink-users] EMBOSS: dependency problems on X86_64
From:       "=?utf-8?b?RGFuaWVsIE1hY2tz?=" <dmacks () netspace ! org>
Date:       2010-09-07 6:00:48
Message-ID: 20100907020048.b2rxbf70cdkosw4o () webmail ! netspace ! org
[Download RAW message or body]



On Tue, 24 Aug 2010 20:27:36 -0400, Alexander Hansen  wrote:
-----BEGIN PGP SIGNED MESSAGE-----
  > Hash: SHA1
  >
  > On 8/24/10 6:46 PM, Scott R. Santos wrote:
  > >
  > > Hi Dan,
  > >
  > > Thank you for taking over the maintenance of EMBOSS.  A couple of 
things I noticed:
  > >
  > > 1) While the "slimmed" down version of plplot have reduced the 
dependency load of EMBOSS on i386, its still fairly high (at least 85 
additional packages), including python and postgresq.  If possible, it 
would be great to have the possibility to install and maintain EMBOSS 
via fink without all of these "extras" (whose absence in prior releases 
or when compiling from scratch have not impaired my use of this 
software suite). 
  > >
  >
  > The current emboss package carries an explicit dependency on
  > postgresql84, but python is coming in indirectly. 
  >
  > It's quite possible that what you are seeing is due to updates in the
  > chain.  Fink tends to be overgenerous in specifying dependencies because
  > that's an easy way to avoid having packages build differently on
  > different systems--and some packages have functionalities based on what
  > they detect which aren't easily turned off. 
  >
  > We also tend to build more than just the core functionality of a
  > package, and include all of the bindings, etc. that get built by
  > default.   That can lead to a large number of packages that get built
  > but not installed. 
 
Alex has it exactly: the original packaging I inherited "sometimes" 
linked against various sql libraries, and that sort of variability is 
forbidden for fink packages (it acted as a non-stated dependency). I 
had assumed people would want database support (continuing the same 
feature-set I observed previously), so I added the dependencies to make 
sure that would happen. Now it builds with the same supported-features 
for everyone rather than apparently randomly (from non-technical users' 
perspective) having them or not on different machines or with repeated 
recompiling. 
 
Given that it can apparently build without (for example) postgresql, it 
would be easy to make a package that always does not have that feature. 
There might be a ./configure flag or similar build-time setting. You 
could edit the package on your local systems to make that sort of 
adjustment. It's easy to hack fink packages, feel free to ask for more 
info!
 
However, the database support is not a plugin/addon, so we can't have, 
for example, "emboss-core" and then a separate "emboss-postgres" addon. 
We could have an "emboss-nodb" that was without database support, and 
you could install *either* emboss or emboss-nodb, but users are 
perpetually confused when they have to make choices like that (I don't 
know why). Due to the nature of this specific set of packages, it would 
also be a maintenance nightmare. 
 
dan

  --
Daniel Macks
  dmacks@netspace.org

 


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Fink-users mailing list
Fink-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-users

[prev in list] [next in list] [prev in thread] [next in thread]