tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wip/tme ready for review

On 2015-07-15 06:05, Greg Troxel wrote:
Thomas Klausner <> 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

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

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.


Home | Main Index | Thread Index | Old Index