Re: Packaging MB-System, some questions
Hi Hamish,
On Fri, Aug 30, 2013 at 07:01:39PM -0700, Hamish wrote:
> Hi,
>
> I'm currently packaging up MB-System software for inclusion in Debian,
>
> http://www.ldeo.columbia.edu/res/pi/MB-System/
> http://anonscm.debian.org/viewvc/pkg-grass/packages/mbsystem/trunk/debian/
> https://wiki.debian.org/DebianGis/PackageList#Lower_Priority
>
> in parallel with upstream converting to Autoconf instead of a custom
> Makefile method.
>
>
> three questions:
>
> -- the watch file:
>
> New releases are posted on a FTP site*, and the version numbering is
> like major.minor.svn_rev. On the FTP site the latest release is simply
> named <package_name>.tar.gz, which is a symlink back to the versioned
> filename. That would be fine, except for sometimes development snapshots
> are uploaded to the FTP site with the same x.y.rev naming scheme as a
> full release, but those never get symlinked to the package.tar.gz name.
> How to deal with that? Just watch for x.y.rev and if a dev version gets
> posted (rare, but it happens) just ignore the message in the PTS?
>
> [*] ftp://ftp.ldeo.columbia.edu/pub/MB-System
Because there is no technical way to let uscan check the given symlink
IMHO the best way would be really to ignore the "new version" in PTS in
case this might really happen. The only reasonable way would be to
teach upstream to add some x.y.rev-devel or something like this - just
anything you could exclude via regexp.
> -- the automated copyright file:
>
> Are there devtools for automatically creating that template? This software
> is pretty easy, mostly by a couple of authors who still lead the project,
> and stuff not by them is either bundled libraries which in the debian
> package will be removed in favor of official debian packages, or are DFSG problematic and built --without. So not a major complicated thing to untangle but if there's a way to make creating the automated copyright file easier I'd
> be keen to know about it.
Not that I would be aware of.
> -- GMT paths:
>
> Debian's GMT package does a funny thing with the GMT package, it installs
> the 140 binary programs into /usr/lib/gmt/bin instead of directly into /usr/bin.
> See `man GMT` for an explanation and wrapper script. (is there a historical thread discussing this?)
>
> I'm guessing this is to keep /usr/bin/ from being overloaded, but is it
> still desirable and needed to do that? MB-System makes heavy use of the
> GMT programs, and is designed in a similar way with 74 of its own command
> line do-one-thing-well programs and scripts. Path-patchching all of the system() calls to gmt programs and code that generates run-time auto-generated shell scripts too would be a huge patch, and one I'd rather avoid. My current solution (which I'm not really happy with either) is to add a file to /etc/profile.d/ called gmt_path.sh containing
> PATH="$PATH:/usr/lib/gmt/bin"; export PATH
>
> Better ideas? Should I file a wish to move GMT binaries back into /usr/bin?
The usual reason to move a set of binaries from /usr/bin to
/usr/lib/<pkg>/bin is to avoid name space conflicts. Unfortunately when
having such a number of binaries most probably one or to with short or
generic names have the same name in common with some totally inrelated
binary from some other package in Debian. Your solution to set the PATH
accordingly might be a reasonable addition to the wrapper script.
This discussion is raised about once per year in every Blend and we
had some discussion to use some common PATH like
/usr/lib/debian-gis/bin
and move all the GIS tools there. But finally this is not really better
than your solution.
Hope this helps
Andreas.
--
http://fam-tille.de
Reply to: