Created attachment 222013 [details]
Share file of the nq port
This port provides the nq (enqueue) command line tools. These tools can be used to create queues of jobs which will run one at at time in the background of the shell. Job order and queuing is handled by file locks.
The original project is available under the public domain and can be found here: https://github.com/leahneukirchen/nq
Thanks for your submission, a few issues however that needs attention
Please have a look at "Example 5.12. Use of USE_GITHUB with DISTVERSIONPREFIX " in Porter's Handbook - https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description
LICENSE_FILE= entry is missing
Seems to compile fine without gmake? (Remove USES line)
Projects Makefile overrides CFLAGS and potentially other variables such as PREFIX set by framework
The general solution for the other variables is to use ?= instead of =
Fix --> 4.4. Patching and preferably if possible submit changes upstream
Created attachment 222015 [details]
Port of nq - second attempt
I've made the suggested changes and attached an updated version of the port.
I'll get in touch with upstream to see about changing the Makefile variables for future releases.
Adding one more update here. This updates the port to use a new commit and does away with the need for a separate patch file.
Created attachment 222016 [details]
Third version of port, now without needing to patch Makefile
PORTVERSION --> DISTVERSION
"Example 5.12. Use of USE_GITHUB with DISTVERSIONPREFIX"
I would strongly advice you not to fork upstream especially when upstream is still active and on top of that increment version numbers as this makes breaks our tools for automatic checks of updates. This will also break as pkg-descr refers to upstream repo
Instead apply your changes as patches which can be easily accomplished and don't increment upstream version.
Revert back to upstream, add your patches to the ports Makefile (unless it requires ~4+ files)
Please run portlint and if possible poudriere
I apologize for sounding a bit pedantic but it really easies maintenance burden if we all try to follow the handbook as close as possible and it makes it a lot easier for the next person to tell what's going on/what you're trying to accomplish.
Isn't nq already in the ports BTW? https://www.freshports.org/sysutils/nq
That is really weird. I did a search for nq on FreshPorts the other day before I started work on the port and got no results. Guess it's already ported.
The reason I forked upstream is the maintainer doesn't seem to have done any work on nq in the past four years and has rejected any porting/documentation pull requests. It's less about getting the new Makefile in place and just gaining a chance to keep working on it.
Bottom line is I plan to continue the source fork whether it's useful for the FreeBSD port or not, so we might as well use it.
Though now I'm thinking maybe it makes more sense to submit a patch against the existing nq port rather than get this one committed.
(In reply to daniel.engberg.lists from comment #1)
> The general solution for the other variables is to use ?= instead of =
The most practical solution for that is to just override them in
MAKE_ARGS instead of patching it. Sometimes that is not possible but
here it is. The nq port already does this and it is what upstream wants
as well as explained in https://github.com/leahneukirchen/nq/pull/20
(In reply to jsmith from comment #7)
> The reason I forked upstream is the maintainer doesn't seem to
> have done any work on nq in the past four years and has rejected any
> porting/documentation pull requests.
Ok, look... None of that seems to be true. If we discuss something like
this can we try to do it on some kind of material basis.
1. nq is stable and simple. There is no reason why there would have
been a lot of work on it.
2. The last release was in March 2018. That was ~3 years ago.
3. Leah is active elsewhere on GitHub. It is not like she disappeared
for 3 years.
4. All new pull requests were done in the last 28 days and no
reasonable time frame for merging them was given before forking.
Actually all PRs have been merged or given good explanations
as to why they have been rejected.
There is no basis for forking and switching the package over to it.
Anyway I'll take nq back now and bring in the kqueue patch which seems
to be what this PR boils down to.
A commit references this bug:
Date: Fri Feb 26 09:28:37 UTC 2021
New revision: 566591
sysutils/nq: Update to v0.3.1-6-g8165cee
This adds kqueue support to fq(1).