Bugzilla Bug 10956

Hi,
the Generic Mapping Tool is a powerfull map generator. An interesting tool for
geophysical sciences.

I'm submiting the gmt-3.4.2_beta3.ebuild. Maybe isn't more necessary to use the
variable "INSTALLDIR" nor to include the "40gmt" in the env.d

The official site description:
########
GMT is a free, open source collection of ~60 UNIX tools that allow users to
manipulate (x,y) and (x,y,z) data sets (including filtering, trend fitting,
gridding, projecting, etc.) and produce Encapsulated PostScript File (EPS)
illustrations ranging from simple x-y plots through contour maps to artificially
illuminated surfaces and 3-D perspective views in black and white, gray tone,
hachure patterns, and 24-bit color. GMT supports 25 common map projections plus
linear, log, and power scaling, and comes with support data such as coastlines,
rivers, and political boundaries. 
######

Created an attachment (id=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 an attachment (id=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 an attachment (id=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

(From update of attachment 10702 [details])
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 ***