Bug 165767 - [maintainer patch] astro/merkaartor update to 0.18-dev in order to fix build with boost-1.49
Summary: [maintainer patch] astro/merkaartor update to 0.18-dev in order to fix build ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Carlo Strub
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-06 02:40 UTC by Oliver Heesakkers
Modified: 2012-03-16 21:20 UTC (History)
0 users

See Also:


Attachments
file.diff (3.11 KB, patch)
2012-03-06 02:40 UTC, Oliver Heesakkers
no flags Details | Diff
merkaartor-0.18.a.patch (4.55 KB, patch)
2012-03-06 14:04 UTC, Oliver Heesakkers
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Heesakkers 2012-03-06 02:40:08 UTC
From this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/156253 (an update for boost) an e-mail found its way to me warning me of breakage and requesting action.

This update updates to the latest Merkaartor snapshot from git. This means that Merkaartor no longer depends on boost. Sadly, as upstream development is not very active at this point in time, there is no real release for 0.18 now or in the foreseeable future. Despite being a snapshot, the program is stable.
The snapshot tarball is hosted by me.

The alternative to build 0.17.2 with built-in boost (1.38) does not work reliably with a newer boost installed on the system.
Comment 1 Oliver Heesakkers 2012-03-06 13:43:37 UTC
Scratch that patch, a better one is underway
Comment 2 Oliver Heesakkers 2012-03-06 14:04:34 UTC
New patch:
- tweak PORTVERSION to prevent confusion with future releases,
- remove proj and gdal from options as they are now required.
Comment 3 Carlo Strub freebsd_committer freebsd_triage 2012-03-06 21:09:14 UTC
Responsible Changed
From-To: freebsd-ports-bugs->cs

I'll take it
Comment 4 Carlo Strub freebsd_committer freebsd_triage 2012-03-11 20:06:44 UTC
Here some feedback. First, my tinderbox swallowed your patch very well and =
everything seems to compile perfectly. Regarding the new snapshot, I have t=
he following one suggestion:

It seems to me that we should bump PORTEPOCH and then use a more visible po=
rt version, e.g. date (20120315) or first digits of git revision, etc.

What do you think?
Carlo

--
Carlo Strub
Ports committer
--=
Comment 5 Carlo Strub freebsd_committer freebsd_triage 2012-03-11 20:07:21 UTC
State Changed
From-To: open->feedback

Awaiting feedback
Comment 6 Oliver Heesakkers 2012-03-11 21:26:09 UTC
Op zo 11 mrt 2012 21:06:44 schreef Carlo Strub:
> Here some feedback. First, my tinderbox swallowed your patch very well and
> everything seems to compile perfectly. Regarding the new snapshot, I have
> the following one suggestion:
> 
> It seems to me that we should bump PORTEPOCH and then use a more visible
> port version, e.g. date (20120315) or first digits of git revision, etc.
> 
> What do you think?
> Carlo
> 
> --
> Carlo Strub
> Ports committer
> --

From what I've read PORTEPOCH should not be set unless absolutely necessary (to
fix a mistake or something:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#AEN560
So I'd rather not set that.

I took the example here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#AEN752
for marking a port alpha, but I guess 0.18 < 0.18.a so when a real release
happens you couldn't call it 0.18, but would have to call it 0.18.b or 0.18.c,
etc.

I'd be happy to call it 0.17.20120304 (the checkout date), but the program runs
as 0.18, I could edit Config.pri further to correct that, but I fear that would
only cause further confusement, especially when a user asks questions upstream.

Another option then is to call the port 0.18.20120304 and for any subsequent
release in the 0.18 branch maintain and update the date suffix. The one patch
the port now has, adds "-dev" to the windowtitle and the about-dialog to remind
the user that (s)he is using a development version, that patch can be dropped
when a real release is made.

Thinking about it, I favor the last option. If you agree, I'll adjust the patch
and the distfile accordingly.

Regards,

	Oliver
Comment 7 Carlo Strub freebsd_committer freebsd_triage 2012-03-11 22:24:37 UTC
Hmm. This is a tricky question to answer correctly. On the one hand you are=
 right that PORTEPOCH should not be used extensively, on the other hand nam=
ing it 18.a may be misleading users in thinking that this was an official a=
lpha release. To be honest, I have no super strong opinion on it. Let me co=
ntact my mentors to ask for advise. I'll get back to you. In case we have d=
ecided on a good solution you don't need to resend the patch. I can fix tha=
t then.

Best,
Carlo=
Comment 8 Oliver Heesakkers 2012-03-12 19:56:07 UTC
Running some tests with pkg_version -vL= and PORTVERSION, the ports versioning 
system actually handles those letters as you would expect from the examples.

merkaartor-0.18.a < needs updating (port has 0.18.20120304)
merkaartor-0.18.a < needs updating (port has 0.18)
merkaartor-0.18.20120304 > succeeds port (port has 0.18)
merkaartor-0.18.a.20120304 < needs updating (port has 0.18)

So using 0.18.a would work when a 0.18 is released later,
using 0.18.20120304 would not work unless you maintain and update the date 
suffix until 0.19 arrives.

0.18.a.20120304 would also work and I think I like it best. The 'a' tells the 
ports system that this stuff is pre-release, adding a date string is a sign to 
the user that something "special" has been done. Once a 0.18 is released, 
simply naming it that will obsolete any and all 0.18.a versions.
Comment 9 Greg Larkin freebsd_committer freebsd_triage 2012-03-14 17:56:38 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

As Carlo's mentor, he asked me to review this PR for my opinion on the
version string convention.  From the looks of it, you've both narrowed
it down to a version string that's constructed similarly to other ones
already in the ports tree.  I ran a quick analysis:

# cut -f1 -d\| /usr/ports/INDEX-8 | egrep "\.[ab]\.?[[:digit:]]+" | sort
| grep 201

There is a handful of ports that include a ".a" or ".b" as well as a
date stamp.  If you invert the grep, you'll find there are 100+ that
only use ".a" or ".b" with a simple incrementing number.

Each form is acceptable, with one more commonly used than the other.

Regards,
Greg

- --
Greg Larkin

http://www.FreeBSD.org/           - The Power To Serve
http://www.sourcehosting.net/     - Ready. Set. Code.
http://twitter.com/cpucycle/      - Follow you, follow me
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9g29YACgkQ0sRouByUApCMKQCcCNRI3dHQ1M4KqbxqcRP5t1dS
Q+YAoI/MbG+FmjzRsRfelEzYsxgKEn9n
=rSbH
-----END PGP SIGNATURE-----
Comment 10 dfilter service freebsd_committer freebsd_triage 2012-03-16 21:12:27 UTC
cs          2012-03-16 21:12:17 UTC

  FreeBSD ports repository

  Modified files:
    astro/merkaartor     Makefile distinfo pkg-plist 
  Added files:
    astro/merkaartor/files patch-src__Config.pri 
  Removed files:
    astro/merkaartor/files patch-src__Sync__DownloadOSM.cpp 
  Log:
  - Update to last git snapshot version (no official release for a long time)
  - Remove boost dependency
  - Remove GDAL and PROJ options as they are now required
  
  PR:             ports/165767
  Submitted by:   Oliver Heesakkers <dev2@heesakkers.info> (maintainer)
  Approved by:    glarkin@ (mentor, implicit)
  Feature safe:   yes
  
  Revision  Changes    Path
  1.21      +5 -20     ports/astro/merkaartor/Makefile
  1.9       +2 -2      ports/astro/merkaartor/distinfo
  1.1       +10 -0     ports/astro/merkaartor/files/patch-src__Config.pri (new)
  1.2       +0 -11     ports/astro/merkaartor/files/patch-src__Sync__DownloadOSM.cpp (dead)
  1.6       +2 -3      ports/astro/merkaartor/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 11 Carlo Strub freebsd_committer freebsd_triage 2012-03-16 21:12:36 UTC
State Changed
From-To: feedback->closed

Committed. Thank you very much.