| Summary: | sci-chemistry/apbs some env variables should be set | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Justin Lecher (RETIRED) <jlec> |
| Component: | New packages | Assignee: | Markus Dittrich (RETIRED) <markusle> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | sci-chemistry |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 213616 | ||
--- apbs-0.5.1.ebuild.orig 2008-01-12 15:06:35.000000000 +0100
+++ apbs-0.5.1.ebuild 2008-03-14 08:26:26.000000000 +0100
@@ -69,4 +69,8 @@
insinto /usr/share/${PF}/tools
doins -r tools/* || die "failed to install tools"
+ cat >> "${T}"/20apbs <<- EOF
+ APBS_BINARY="/usr/bin/apbs"
+ APBS_PSIZE="/usr/share/${P}/tools/manip/psize.py"
+ EOF
}
Thats the right one!
Hi Justin, Thanks much for the note. It looks like these environmental variables are specific to pymol rather than apbs and should, therefore, be exported by the former rather than apbs. What do you think? Thanks, Markus Hi Markus, it's a bit tricky. Since apbs is not a dep of pymol, there would be a pointless env entry. Two ways to escape: First put it in apbs. Second introduce a USE flag in pymol which pulls in apbs and sets the env. Perhaps you are right and that way is more elegant. Or apbs should become a default dep of pymol as the plugin interface is installed anyway. (no-apbs USE flag for those who don't want apbs support?) Hi Justin, > it's a bit tricky. Since apbs is not a dep of pymol, there would be a pointless > env entry. The same would be true the other way round. All users of apbs who don't happen to use pymol would have an unused entry. > Second introduce a USE flag in pymol which pulls in apbs and sets the env. > > Perhaps you are right and that way is more elegant. Or apbs should become a > default dep of pymol as the plugin interface is installed anyway. (no-apbs USE > flag for those who don't want apbs support?) > I think your second option is the better one. Unfortunately, I don't know pymol very well but it seems to me that if pymol has a plugin for apbs it should also depend on the latter. Otherwise users have some functionality (the plugin) that doesn't work. An apbs use flag for pymol would be a possibility but only if one could actually disable the plugin from being present for USE="-apbs"; otherwise users again are presented with a non-functioning plugin interface. How does that sound? cheers, Markus Fixed with solution from #229687. |
Some programs e.g. pymol need some env variables for apbs to be set. Following diff for the new ebuild would provide the necessary things: --- apbs-0.5.1.ebuild.orig 2008-01-12 15:06:35.000000000 +0100 +++ apbs-0.5.1.ebuild 2008-03-14 08:26:26.000000000 +0100 @@ -69,4 +69,8 @@ insinto /usr/share/${PF}/tools doins -r tools/* || die "failed to install tools" + cat >> "${T}"/20apbs <<- EOF + APBS_BINARY="/usr/bin/apbs" + APBS_PSIZE="/usr/share/${PV}/tools/manip/psize.py" + EOF } Reproducible: Always