|
cc'ing the list -------- Message original --------
Le 8/18/11 6:01 AM, Aaron M. Ucko a écrit : > [Sorry for the belated reply; I was on vacation when this thread started > and have only just caught up to it.] > > Tim Booth <avarus@fastmail.fm> writes: > >> These don't break the build but they should really be disabled. Is >> there an easy way to do this, do you think? > Yes, just comment out the relevant per-project makefiles' CHECK_CMD settings. I will try to have a look to patch this in the package. However I will go on vacation end of this week. So it will not be done before some time... > >> A user reported that his analysis took an order of magnitude longer >> after upgrading BLAST+ (from the static binary build to the Debian Med >> build). I'd expect some slowdown with dynamic linking but this is >> indeed fairly drastic: > Dynamic linking does indeed add a fair bit of startup overhead. :-/ > OTOH, the BLAST+ executables support input files containing multiple > queries, which should reduce its impact (but may entail reworking some > scripts). Regarding speed, for real case analysis, it not be too impacting, as library load should be insignificant compared to blast work itself. >> If the latter, I know the real fix is for script authors use BLAST more >> sensibly, but I'm wondering if there is any mileage in trying to make a >> ncbi-blast+-static package? > That's an interesting idea, but it would probably be pretty hefty. As > far as logistics go, I'd suggest that it provide/conflict/replace > ncbi-blast+ (and ship separate copies of its handful of > architecture-independent files) rather than pretending to be > coinstallable. > I am not really fond of providing 2 packages (one dynamic/ one static). Furthermore, static one would be really large, poor debian servers ;-) Olivier gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 |