Page MenuHomeFreeBSD

biology/trimadap: Trim adapter sequences from Illumina data
ClosedPublic

Authored by jwb on Apr 2 2018, 6:19 PM.

Details

Summary

biology/trimadap: Trim adapter sequences from Illumina data

Approved by: jrm (mentor) or wen (mentor)

Test Plan

portlint -AC: Looks fine
Passed poudriere testport {10.3,11.1}-{amd64,i386}
Differential to be added to commit log

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

biology/trimadap/Makefile
18–23 ↗(On Diff #40997)
CFLAGS_i386= -msse2
biology/trimadap/Makefile
4 ↗(On Diff #40997)

The PH advises

DISTVERSION=	0.1-3
DISTVERSIONSUFFIX=	-gddfef21

and then you can remove GH_TAGNAME= ddfef210563830d9193b40949da3523b6fb93003 below. I am concerned that I am missing something here though, since @mat did not suggest this.

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!

biology/trimadap/Makefile
18 ↗(On Diff #41020)

Why +=?

4 ↗(On Diff #40997)

As long as 0.1-3-gddfef21 is the result of a git describe --tags, this looks good, yes.

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:

  1. released tarball
  2. archive from a tag
  3. archive from a git describe --tags output that is not a tag
  4. 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)

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.

In D14935#314229, @jwb wrote:

We had a discussion about this a couple months ago and concluded that using PORTVERSION is the only way to specify a patch level.

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.

This revision is now accepted and ready to land.Apr 3 2018, 5:01 PM

Agreed. Now that I'm aware of all the USE_GITHUB support for cases like this, I am definitely inclined to utilize it.

This revision was automatically updated to reflect the committed changes.