biology/trimadap: Trim adapter sequences from Illumina data
Approved by: jrm (mentor) or wen (mentor)
Details
Details
- Reviewers
jrm wen - Commits
- rP466367: biology/trimadap: Trim adapter sequences from Illumina data
portlint -AC: Looks fine
Passed poudriere testport {10.3,11.1}-{amd64,i386}
Differential to be added to commit log
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| biology/trimadap/Makefile | ||
|---|---|---|
| 18–23 ↗ | (On Diff #40997) | CFLAGS_i386= -msse2 |
Comment Actions
Maybe you're looking at the p20170211 as a pre-release level? It's actually a post-release patch level. 0.1.p20170211 would be a pre-release, 0.1p20170211 is a patch level. Rather confusing, I think, but at least it's documented. We had a discussion about this a couple months ago and concluded that using PORTVERSION is the only way to specify a patch level.
I often use patch levels for projects that don't have a well-established release schedule, e.g. much of the genomics software pool. Seems like the only reasonably safe strategy not knowing if or when another release will come or how it will be tagged.
I also want to be descriptive with the versions so users can easily determine the vintage they're using.
Do you think something like DISTVERSION=0.1-20170211 would be preferable? That would be a break from the pattern I've been following and I'm not sure it's semantically correct for specifying post-release patch levels. I verified that it does work with USE_GITHUB, but I cannot switch ports using PORTVERSION=x.ypYYYYMMDD over to this scheme as it would break the version progression:
<<<ROOT@cray.acadix>>> /usr/ports/biology/trimadap 1056 # pkg version -t 0.1p20170211 0.1.20180101
Thanks!
Comment Actions
Please see Example 5.14. Using USE_GITHUB to Access a Commit Between Two Versions. What @jrm proposes is correct. The only time you use a date based version is when nothing else is available. For Git based distfiles, the order into which you can look into things is:
- released tarball
- archive from a tag
- archive from a git describe --tags output that is not a tag
- archive from a commit hash with the version using the date of the commit
steps 2 and 3 can be combined, git describe --tags knows to give you the tag without -0-ghash. (see note at the end of example 5.14)
Comment Actions
I see, I was only looking at the Naming section and didn't realize there was
more about this under USE_GITHUB. This is very nice...
CGLAGS_i386: Makes sense that this is automatically appended (unlike CFLAGS),
so no += needed.
Comment Actions
Iirc, that was a bit different because upstream did something weird with the latest tag?
I also want to be descriptive with the versions so users can easily determine the vintage they're using.
Imo, this is a reasonable argument for setting PORVERSION directly with a date, but I think we are both sticklers for consistency. That is one reason I lean towards the current solution. It's not ideal, but users could look at the tag in the package version and see from GH exactly what they are using, whereas many commits could be made on the same day, so the date could be ambiguous.
Do you think something like DISTVERSION=0.1-20170211 would be preferable?
My interpretation of the PH is that DISTVERSION is only set to something that really exists upstream and PORTVERSION should only be set directly when the automatic translation from DISTVERSION to PORTVERSION does not work.
Comment Actions
Agreed. Now that I'm aware of all the USE_GITHUB support for cases like this, I am definitely inclined to utilize it.