Allowing float version numbers

[MarcelBochtler]

Fixes a problem which occured on the latest Manjaro Linux update of wpa_supplicant from 1:2.6-8.1 to 1:2.6-11

[mikkeloscar]

I'm not sure about this. It will parse a float and later convert it to an uint8 which kind of defeats the purpose if used for version comparison.

It's stupid that Manjaro is introducing custom rel values which aren't compatible. It should either be an int or of the format Major.Minor but not both.

One solution would be to always treat the rel as Major.Minor and parse something like 1:2.6-11 as 1:2.6-11.0. I'll accept this if you want to add this feature. Please add tests if you do so.

[MarcelBochtler]

It's stupid that Manjaro is introducing custom rel values which aren't compatible. It should either be an int or of the format Major.Minor but not both.

Do you have a link to the documentation which says that?
Because if this versioning is not standard/allowed it should not be dealt with in here. I'll ask the Manjaro Devs about this.

[mikkeloscar]

The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.

From https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel

It doesn't explicitly say that you can't use both formats, but if you think about it, it doesn't make sense to compare two formats unless it's clearly defined how they should be compared. The comparison code used in gopkgbuild is based on that of pacman, which I would consider the truth. I would have to look at the pacman code to see if they can handle this case, since I don't remember.

I appreciate you talking the time to contribute, I just don't think it's the right solution as-is.

[MarcelBochtler]

I would have to look at the pacman code to see if they can handle this case, since I don't remember.

Pacman was able to handle it. I updated this package with it.

I appreciate you talking the time to contribute, I just don't think it's the right solution as-is.

No problem at all. I was curious if I would be able to find the problem, but wasn't 100% sure about my solution either ;)

[mikkeloscar]

@MarcelBochtler I think it makes sense to parse the rel as a version rather than an int. Changed it in #3 can you test if this works for you?

[MarcelBochtler]

Yes, this fixes my issue.
Thank you :)