| Summary: | gmt-3.4.2.ebuild (New Package) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Castelão <castelao> |
| Component: | Current packages | Assignee: | George Shapovalov (RETIRED) <george> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | enhancement | CC: | castelao |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://gmt.soest.hawaii.edu/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Generic Mapping Tool
Some corrections suggested by George Stable version |
||
|
Description
Castelão
2002-11-19 06:37:27 UTC
Created attachment 5787 [details]
Generic Mapping Tool
This is the beta 3 release, but maybe it's working fine.
In the future versions we could include more resources of GMT.
Hi Castel Hi Castelão.
Thank you for your submission!
Unfortunately there are fe problems with the ebuild.
The major one:
I noticed you do some name mangling in order to remove the _beta fron the ${PV}
part and use that for defining the SRC_URI's, meaning that URI's do not contain
full versioning info. This cannot be left in such form, because when final
version is released it is likely to maintain present name and will have a
potentioal for silent breakage.
There are ways to go about it. On our side we can mirror necessary sources
after renaming them to contain all necessary versioning. However this makes this
ebuild quite laborous to maintain. It is always preferable to try to solve the
problem upstream.
We can try to persuade package developers to rename sources. Or if this
package is close to final release, we can just wait until non-beta is released
and add it to portage then. Could you please clarify the status of this package:
like when the release is going to happen and how important is to get this ebuild
processed (are there any other packages that might depend on it) and what is the
general naming policy?
Some minor points:
1. it is not necessary to define INSTALLDIR, you can just use /usr instead.
The situation here is that all the packages have to adhere to FHS
sspecifications (Filesystem Hierarchy Standard). According to it all the
packages managed by distribution should go into /usr and /usr/local should be
left at the discretion of the sysadmin (the user). Basically the end user is
supposed to manually install packages into /usr/local (and this is why --prefix
in pretty much all configure scripts defaults to /usr/local) and we are not
allowed to touch that.
Thus you can safely use /usr without defining the INSTALLDIR. You can also keep
this war defined, though if you chose so please change itsinvokation everywhere
from $INSTALLDIR to ${INSTALLDIR} form for consistency with all other vars.
2. ./configure --prefix=$INSTALLDIR
can be replaced with econf, which will also set ---mandir and --infodir correctly.
3. Please check that there are no trailing spaces/tabs in the ebuild and that
the indentation is done through tabs (I think this is the case, just listing
this here as this is a formatting convention in ebuilds). Good idea is to pass
the ebuild through lintool, which is now a separate package. You can emerge
lintool and then just check the output of "lintool pkgname-PV.ebuild" for the
complaints.
Thanks again for your work!
George
Created attachment 6208 [details]
Some corrections suggested by George
As suggested by George the GMT is now installed in /usr not more in /usr/local.
Don't use more the variable $INSTALLDIR.
As other applications, the lib, include and share archives are placed in
sub-directories "gmt-${PV}".
lintool warn about "Testing for presence of env vars" that I didn't understand.
As suggested in the GMT compile instructions was included a export of the
variable "NETCDFHOME".
Hi Castel Hi Castelão. Ok, this looks good now. I have checked the ebuild and committed it (keymasked). Please test. George There is a problem with paths!
The coastline and bathymetry database of GMT could be bigger if the user choose higher resolutions. For that I didn't put this dataset directly in /usr/share, but in /usr/share/gmt-${PV}. For that is necessary to include in /usr/share a file called "coastline.conf" that have the right path to dataset. In this case will be "/usr/share/gmt-3.4.2".
Any suggestion better than only
echo /usr/share/gmt-${PV} > /usr/share/coastline.conf
in ebuild file?
db fix db fix Created attachment 10702 [details]
Stable version
Probablly not the best solution but a stable one.
Hi Castel Hi Castelão. Thanks for testing, remarks and everything! Could you please reopen the bug when you add comments that require attention other that "it works"? Otherwise the bug does not show on my radar screen ;). Sometimes bugzilla skips on notification emails (which seems to have happened here), so I really have no way of knowing if the bug has changed unless it reappears in my list of open bugs. It was fortunate you emailed me directly :). Ok reopening the bug now, will try get to it reasonably soon. George Comment on attachment 10702 [details] Stable version Obsolete by bug 23977 Thanks for an update! Will try to get to the new one soon. George *** This bug has been marked as a duplicate of 23977 *** |
