Hi, just an idea for now. But what you think about multiversion ebuilds? Technically this could be realized with the following line in the ebuild itself: ``` VERSIONS=( 3.0.11 3.0.12 3.1 ) ```
and the filename without version:
<dev-category>/<package-name>/<package-name>.ebuild
together with this set of rules:
1. If there is an ebuild with had a version in its name, this ebuild is
preferred.
e.g. is a tree consists of "foobar/foobar-1.1.ebuild" and
"foobar/foobar.ebuild" for version 1.1 the specific ebuild is taken.
2. If the ebuild has the variable VERSIONS specified but also a version in its
name, the version in its name is taken.
3. There can be only one multiversioned ebuild per package.
Different version keywording can be done as before:
```
if [[ ${PV} == "3.1" ]] ; then
KEYWORDS="~amd64 ~x86"
else
KEYWORDS="amd64 x86"
fi
```
The resolution of versions can be done as before, with the difference that one
ebuild can represent multiple versions.
The "ebuild" tool needs some adjustments. Maybe it tries to download and build
all version per default and has an additional flag to specify a single version.
The advantages of this idea I see are:
- Ebuilds are written in a multiversion manner anyway, and then get copied (or
linked?), so it can be made explicit.
- The diffs between different versions of ebuilds and the commit history are
way more readable.
- The size of the tree reduces.
Regards,
Gerion
signature.asc
Description: This is a digitally signed message part.
