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:

together with this set of rules:
1. If there is an ebuild with had a version in its name, this ebuild is 
 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"
        KEYWORDS="amd64 x86"

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.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to