Re: wip/tme ready for review

[phabrics%phabrics.com@localhost]

On 2015-07-15 06:05, Greg Troxel wrote:
> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
>
> > On Wed, Jul 15, 2015 at 12:29:30PM +0200, Kamil Rytarowski wrote:
> > > - - Version 0.10beta_6 - can we make it saner? Alphanumerical 
> > > versions
> > > tend to introduce issues with maintaining upgrades and comparing
> > > version. Do you know whether 0.10 > 0.10beta_6 for pkgsrc? For RPM 
> > > and
> > > pkg-config it's false.
> >
> > If you make it 0.10beta6 it's ok for pkgsrc (<0.10).
>
> From a numbering POV, yes.  But generally pkgsrc discourages packaging
> beta/etc. and prefers releases.   Of source, sometimes it is in the 
> best
> interest of users becuase there is a beta and there isn't a release for
> some reason.  But when the packager is the upstream author, I think it
> makes sense to ask for these things to be cleaned up upstream.
>
> My advice on beta etc. is to just use numbers.  We have an infinite
> number of version numbers available, and people are unwilling to use
> them.  If you recommend that people use this instead of 0.8, then call
> in 0.10.  If you don't recommend that people switch to it now, don't
> update pkgsrc.  Calling it beta and wanting to update pkgsrc is
> inconsistent.

OK, I will switch to 0.10.  These were all done during the BETA phase.
I had it at 1.0, but upstream said 0.10 was next, which I assume is 
<0.8.

> I concur with Kamil's comments.
>
> In DESCR, it might be good to clarify that this is a fork/continuation
> instead of a fork/competitor, as I understand you have the original
> author's blessing.

Noted; Will do.

> Definitely MESSAGE is not appropriate; that belongs in
> $(PREFIX)/share/doc/tme/README or whatever, or in tme.1

I will move it over.

> Should the .h files be installed?  Are they a public interface?

I think this was the idea.  This was from the original package, the idea
being to create a modular implementation for external plug-ins.  
However,
this hasn't happened yet, but for now, I think I will just leave it 
alone
unless there are major objections to it.

> COMMENT should just describe what it does; the current one only makes
> sense if you already know what tme is.  (Basically, this should look
> like the tme package with a new maintainer, which is what is really
> happening.)

I will move back to the original one.

> The --disable-recode needs a comment.  It seems like it's addressing an
> upstream bug.

Correct.  Recode currently only works on 32-bit platforms, for reasons 
which
are a bit complex to fix in another release.  An ongoing issue I hope to
correct in some future release, but reasonably fast machines should work 
just
fine without it.

Regards,
Ruben