search

mikkeloscar / gopkgbuild

A golang package for parsing Arch Linux PKGBUILDs
GNU General Public License v3.0
22 stars 5 forks source link

Allowing float version numbers #2

Closed MarcelBochtler closed 6 years ago

MarcelBochtler commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

Yes, this fixes my issue. Thank you :)