[MacPorts] #47684: tmux @2.0 patch attached to allow compilation from git
#47684: tmux @2.0 patch attached to allow compilation from git -------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: haspatch | Port: tmux -------------------------+-------------------------------- 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? -- Ticket URL: <https://trac.macports.org/ticket/47684> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0 patch attached to allow compilation from git --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: wontfix | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Changes (by larryv@…): * status: new => closed * resolution: => wontfix Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0 patch attached to allow compilation from git --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: wontfix | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by larryv@…): Replying to [ticket:47684 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. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Changes (by larryv@…): * status: closed => reopened * resolution: wontfix => Comment: I’ve attached [[attachment:tmux-devel.patch|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? -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by 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? -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by larryv@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by tessarek@…): Hi Larry, Replying to [comment:5 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. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:6 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. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Comment (by tessarek@…): Replying to [comment:7 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 [[attachment:tmux-devel-new.patch|sub-port patch]] that uses git clone to make it work with sf. Let me know what you think. -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:8> MacPorts <https://www.macports.org/> Ports system for OS X
#47684: tmux @2.0_0: create tmux-devel subport --------------------------+-------------------------------- Reporter: tessarek@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: fixed | Keywords: haspatch Port: tmux | --------------------------+-------------------------------- Changes (by larryv@…): * status: reopened => closed * resolution: => fixed Comment: Replying to [comment:8 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 [[attachment:tmux-devel-new.patch|sub-port patch]] that uses git clone to make it work with sf. Let me know what you think.
LGTM, r136253 -- Ticket URL: <https://trac.macports.org/ticket/47684#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts