freebsd: invalid version scheme

[blshkv]

https://repology.org/metapackage/amass/versions
https://github.com/OWASP/Amass/releases
must be 2.6.0

[AMDmi3]

FreeBSD is getting annoying with these fake versions. These are actually caused by the ease of pointing a FreeBSD port to a commit past the tag:

https://github.com/freebsd/freebsd-ports/blob/de29bebff4df192104121856e8673b2344ef2c51/dns/amass/Makefile#L5-L6

There's no way to detect this pattern through the INDEX file we're using. As Repology maintainer I'd probably mark whole FreeBSD as untrusted after a few more cases, but as FreeBSD port maintainer myself I plan to set up an alternative port metadata dump. FreeBSD portstree contain a lot of useful data not available through INDEX which will be useful for Repology.

@yurivict you may have some comments, as you happen to use this pattern (airspy, flann, amass, swh-lv2 ports).

[yurivict]

you may have some comments, as you happen to use this pattern (airspy, flann, amass, swh-lv2 ports).

This pattern is used for 2 reasons:

1. Projects gave up making regular releases, but are still actively developed in the style of a rolling release
2. When the last release doesn't build on FreeBSD, but some later revision does.

Personally, it makes sense to me because this pattern kind-of splits versions and reflects the version as accurately aspossible. It is also partly based on the git's describe function, and is also consistent with semantic versioning, see https://semver.org/.

With this pattern being implemented in the ports framework, it is hard to do anything about it. It was suggested to me by portmgr@FreeBSD.org and used in a lot of ports.

If the latest released version has some problems, like described above, abandoning this scheme leaved no choice but to not port the project, which is a greater evil than having this type of version, IMHO.

Please note how others do similar things: ntk project has a particular version , but one distro uses date as a version: http://repology.org/metapackage/ntk/versions

Also libfilteraudio has the version 0.0.1, but Slack uses 20161122_ada2f4f: https://repology.org/metapackage/libfilteraudio/versions.

I suggest that you should create a bug report for FreeBSD ports framework here https://bugs.freebsd.org/bugzilla/ , and let them deal with this.

[blshkv]

FreeBSD should create an additional suffix instead of extending (faking) the version. For example, we use <version>_p<date> or <version>-r<revision> in Gentoo.

[yurivict]

FreeBSD should create an additional suffix instead of extending (faking) the version. For example, we use _p or -r in Gentoo.

Ok, tell this to portmgr.

[blshkv]

@yurivict I have looked at the freebsd Makefile and didn't get it:

DISTVERSION=	2.6.0-11
DISTVERSIONSUFFIX=	-g1ef5a43

What was the reason of faking -11 in that particular case?
I can't find the upstream commit g1ef5a43 and the current release compiles just fine.

[yurivict]

This isn't faking, this is the way recommended by portmgr. Without -11 it won't get into the version at all.

I agree with you, this isn't an optimal way of dealing with this problem. They should add a tag like DISTVERSIONREV and put -11 there, and then convert it to _p or -r. But I can't do anything about this, this is for portmgr@.

[blshkv]

got it, thank you for the explanation

[AMDmi3]

• It is faking, because end users see this extra version component
• There is a pretty commonly used schema of 1.2.3git20180915 for which I've suggested a minor extension to make it unambigous ([discussion] unified scheme for snapshot versions repology-updater#345), and I don't remember portmgr forbidding it. It's explicit in that it's a snapshot, it does not tied to github or git and does not require commits to be on the same branch or exist at all.