Game Engine/Keyword Versions
From #229 (closed), but I thought it could use its own issue given that this is going to be useful for openmw as well.
Options:
Keyword Versions
E.g. KEYWORDS = "openmw-0.47"
We also would need version ranges as well as versions, so we can say something like >=openmw-0.47
, which gets messy when we also add in testing (~openmw
) and masked (-openmw
) keywords.
Maybe the ranges could be something like ~openmw{>=0.47<1.0}
(inspired by https://bugs.gentoo.org/4315#c29, which discussed it for version ranges for dependencies. It's nice since the range operators are next to the versions, letting us keep the stability operators at the front.
Manually-set Keywords
Basically like how KSP is set up at the moment, except that we won't need to enumerate every possible version keyword, which lets versions be as fine-grained as necessary.
Disadvantage is that it relies on the user to keep it up to date with their actual game engine.
Automatically-detected keyword versions
Like manually set keywords, but with a function set in the profile (or via an optional module?) which is used to determine the current game engine version. This seems slow, but one advantage over doing it as part of a package is that we can run it very early, and it could probably be done asynchronously so that with any luck the version will be ready by the time it's needed.
On the other hand, it would be needed for basically any operation (as opposed to just during dependency resolution), so we'd end up with a significant delay for most, if not all operations (though again, doing it asynchronously could help). (plus, most of the time we should be able to get it from a file rather than from the executable, so we should mostly just have to deal with the time spent setting up the sandbox).
Versions via a package
This would remove the need to have keywords versioned, and remove the need for introducing keyword ranges, but would also mean that we can only have hard dependencies on the engine version, where having versioned keywords would allow us to mark engine versions as stable/testing/untested/masked, which provides much finer control.
This would require changing how live packages work so that they can change their own version (e.g. like what PKGBUILDs do), but we could have packages that, for example, parse the output of openmw --version
, and then report that version.
Unfortunately, because portmod allows installed packages to be used for dependency resolution, it would mean that the dummy package might not get upgraded, so even if something requires, for example, openmw 0.48 when you have 0.47 installed, it may not be enforced if you had the 0.47 version of the dummy package installed already.
This would make #27 more difficult, since it would no longer always be possible to roll back these packages, short of making them a special sort of package which only installs metadata and can be rolled back just by checking out the older version of the db.