tmux @2.0_0: create tmux-devel subport

[tessus (Helmut K. C. Tessarek)]

I've updated the portfile with a new variant that retrieves the latest code from git.

Unfortunately I do not know, if a port install tmux +dev will always fetch the latest code and compile it. Or will it only do so, if the revision in the Portfile is updated? If this is the case, is there a way to force it, when using variant +dev?

[larryv (Lawrence Velázquez)]

Ports that do tip-of-branch fetches are not permitted. Such fetching precludes reproducible builds: A person installing the port on one day might get different software than a person installing the same port the next day, with no indication that this has happened.

There are better ways to create development versions of ports. I’ll try to whip something up.

[larryv (Lawrence Velázquez)]

Replying to tessarek@…:

Unfortunately I do not know, if a port install tmux +dev will always fetch the latest code and compile it.

It will not.

Or will it only do so, if the revision in the Portfile is updated?

Version or revision, yes.

If this is the case, is there a way to force it, when using variant +dev?

No.

[larryv (Lawrence Velázquez)]

I’ve attached a patch​ that adds a tmux-devel subport. To try it, patch the tmux portfile and run port sync.

• It fetches a specific Git commit to ensure reproducibility. To update the port, you’ll just replace the SHA1 and advance the date inside version.
• It fetches a SourceForge snapshot distfile, allowing our mirroring infrastructure to… uh… mirror it. (We cannot mirror Git repositories.)
• It runs autoreconf --install --verbose --force instead of ./autogen.sh. Here’s the output I see; it seems to (more or less) correspond to the commands executed by autogen.sh:

  autoreconf: Entering directory `.'
  autoreconf: configure.ac: not using Gettext
  autoreconf: running: /opt/local/bin/aclocal --force 
  autoreconf: configure.ac: tracing
  autoreconf: configure.ac: creating directory etc
  autoreconf: configure.ac: not using Libtool
  autoreconf: running: /opt/local/bin/autoconf --force
  autoreconf: configure.ac: not using Autoheader
  autoreconf: running: /opt/local/bin/automake --add-missing --copy --force-missing
  configure.ac:19: installing 'etc/compile'
  configure.ac:11: installing 'etc/config.guess'
  configure.ac:11: installing 'etc/config.sub'
  configure.ac:9: installing 'etc/install-sh'
  configure.ac:9: installing 'etc/missing'
  Makefile.am: installing 'etc/depcomp'
  autoreconf: Leaving directory `.'
  

The subport conflicts with tmux, so a user can only have one or the other active at any particular time.

% sudo port deactivate tmux
% sudo port install tmux-devel

Does this look good to you?

[larryv (Lawrence Velázquez)]

create tmux-devel subport

[tessus (Helmut K. C. Tessarek)]

Hi Larry,

Thank you for your answers and your patch. Unfortunately that's not quite what I was looking for. Let me try to explain.

I do understand that git builds might not be stable. I assumed that the port list tmux command would show the short git hash (7 chars) in the output, e.g.:

tmux                           @23e12a7            sysutils/tmux

A lot of projects do not accept bug reports for release builds and require you to try and use git master before submitting a bug. This is not necessarily true for tmux, but tmux has another problem. Releases are rare and therefore I wanted to give macports users the chance to install a development version. Even, if a certain build does not work, most likely the next one will. Also, that's why I used the dev or devel variant to indicate this. We also could output a warning when using a development build.

But as you explained, the Portfile has to be updated every time to pick up a certain hash or pull the latest master, so this approach is not what I intended. It seems to me the port system lacks support for this kind of use.

So right now I'm not quite sure, what I should do. Any ideas?

[larryv (Lawrence Velázquez)]

You’re correct; MacPorts is designed around reproducible builds and explicit port updates. Tip-of-branch ports are only possible through inconvenient workarounds, and we frown on the idea from a policy standpoint.

Your best course of action depends on what your actual goal is.

• Providing users with a development version: A complementary *-devel port is our standard way of doing this (see port echo '*-devel' for a list), and it works well if the maintainer provide regular updates. You’d have to open a new Trac ticket each time, but small, obvious patches are often pushed quickly.
• Doing actual tmux development: A tmux-devel port would work fine for this, although you’d have to track ToT manually. If that sounds onerous to you, you might be better off doing your development outside of MacPorts. MacPorts is first and foremost a software management and distribution system, and only secondarily a development tool. These roles sometimes conflict, as they do here.

[tessus (Helmut K. C. Tessarek)]

Hi Larry,

Replying to larryv@…:

Your best course of action depends on what your actual goal is.

I want to provide users the possibility to get in-between releases of tmux, not one release per year. So maybe the subport is not a bad idea and I update it every month or so.

Personally I do not use macports for development. I use it to install packages. But in case of tmux, these are mostly really old. This is not the fault of macports, but the developers who do not adhere to a standard release cycle.

I have one off-topic macports development question: any chance you switch to git soon? (svn to git migration is not complicated and can be done rather quickly) this would also make it a lot easier to give people write access to certain projects and/or branches. gitolite is great for that.

Opening a ticket, every time I update the git hash for the subport seems tedious. I'm listed as the maintainer for tmux, therefore I should have write access for this port. Or at least write access to a dev branch and you just merge it when you are ok with it.

[larryv (Lawrence Velázquez)]

Replying to tessarek@…:

I want to provide users the possibility to get in-between releases of tmux, not one release per year. So maybe the subport is not a bad idea and I update it every month or so.

Yes, this would be best, I think.

I have one off-topic macports development question: any chance you switch to git soon? (svn to git migration is not complicated and can be done rather quickly) this would also make it a lot easier to give people write access to certain projects and/or branches. gitolite is great for that.

We have discussed the possibility of migrating away from Subversion, but we are not considering it at this time.

Opening a ticket, every time I update the git hash for the subport seems tedious. I'm listed as the maintainer for tmux, therefore I should have write access for this port. Or at least write access to a dev branch and you just merge it when you are ok with it.

We generally don’t grant commit access to individuals without a substantial history of contributions. And waiting on a ticket is not significantly worse than waiting on a pull request.

[tessus (Helmut K. C. Tessarek)]

Replying to larryv@…:

We have discussed the possibility of migrating away from Subversion, but we are not considering it at this time.

Let me know, if you need any help, when you do.

We generally don’t grant commit access to individuals without a substantial history of contributions. And waiting on a ticket is not significantly worse than waiting on a pull request.

I understand, especially in an SVN environment. You are right, waiting on a ticket is not much different than waiting on a pull request, but it still has some overhead. But if you guys are ok with that, I'm fine with it.

I was looking at your patch, but it won't work the way you created it. You can't download snapshots as zip files from sourceforge, at least not automated via command line, because the snapshot is only created when you click on a link in the sf web interface. That's why I don't use sf to host code.

Here's my version of the sub-port patch​ that uses git clone to make it work with sf. Let me know what you think.

[larryv (Lawrence Velázquez)]

Replying to tessarek@…:

I was looking at your patch, but it won't work the way you created it. You can't download snapshots as zip files from sourceforge, at least not automated via command line, because the snapshot is only created when you click on a link in the sf web interface.

Wow, really? Ugh.

Here's my version of the sub-port patch​ that uses git clone to make it work with sf. Let me know what you think.

LGTM, r136253