You are not logged in.
I am working on a project where I'd like to be able to take the version of an Arch package and determine what part is major, minor, etc.
It doesn't have to be perfect for what I'm doing, just reasonably accurate most of them. I've been using the semver package and it gets tripped up by many packages, such as those that use dates. I'm guessing Arch packages don't follow any unified version scheme, so not all of them are semantic versioning, which would explain why semver doesn't work well.
Does anyone know a more general package? My next alternative would be to simply add my own logic case by case for unusual version formats as I encounter them. But I feel like someone must have done this already, after 15+ years of Arch
Offline
Package version can be anything that doesn't contain colons, forward slashes, hyphens, or whitespace. There's no way to make any assumptions at all, other than the version will go up with each release.
Offline
There's no way to make any assumptions at all, other than the version will go up with each release.
And even that assumption is false as it doesn't account for the epoch variable...
Offline
LooseVersion from distutils has worked quite well for me for comparing versions. But this isn't a technical problem, it's a logical one: you want to extract major / minor / etc from version numbers that don't have major / minor / etc parts ... that can't happen.
Version from distutils will get these components for some version strings that meet it's assumptions. Pyalpm is the best python tool for pacman package versions as it's literally what pacman uses ... but pacman doesn't differentiate major / minor / etc.
So the real question is why do you (think you) want to differentiate these components? If you only need to do so for semantic versioned packages, then a simple regex will work.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for the responses everyone. Sounds like I'll ultimately have to write my own logic, but I'll check out LooseVersion and Pyalpm first.
So the real question is why do you (think you) want to differentiate these components? If you only need to do so for semantic versioned packages, then a simple regex will work.
I have a script that I run before updates, that gives parses and tabulates the pending updates. If any of them look like major updates, I like to check out the release notes to see what's changing. Usually, most updates are minor bugfixes and such, so they don't matter as much.
I guess technically, I don't care if it's minor or major version per se. I just care what nth component is changing. So I can sort by n and the "important" updates would bubble up that way. But some packages have versions like "20211129" which is probably better treated as 3 components rather than one. Others have some extra prefix that they basically never change, so actually 2nd or 3rd component is bumped even for major new features.
Offline
Offline
This implementation in pmbootstrap for alpine versions might be close enough if you do not want to depend on libalpm/pyalpm.
https://github.com/postmarketOS/pmboots … 299c8491ad
Last edited by progandy (2021-11-29 21:40:01)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline