| 1 |
Am Samstag, 12. Mai 2018, 15:47:57 CEST schrieb Rich Freeman: |
| 2 |
> On Sat, May 12, 2018 at 8:20 AM Gerion Entrup <gerion.entrup@×××××.de> |
| 3 |
> wrote: |
| 4 |
> |
| 5 |
> |
| 6 |
> > Different version keywording can be done as before: |
| 7 |
> > ``` |
| 8 |
> > if [[ ${PV} == "3.1" ]] ; then |
| 9 |
> > KEYWORDS="~amd64 ~x86" |
| 10 |
> > else |
| 11 |
> > KEYWORDS="amd64 x86" |
| 12 |
> > fi |
| 13 |
> > ``` |
| 14 |
> |
| 15 |
> From a readability standpoint I could see this getting out of hand if we |
| 16 |
> aren't careful. |
| 17 |
I have kind of copied this code from a package, where a 9999 ebuild exists. So it is already there. |
| 18 |
|
| 19 |
> Also, we'd want to keep this simple enough that the simple |
| 20 |
> act of stabilizing a package doesn't introduce regressions (perhaps even in |
| 21 |
> versions that we don't intend to touch). We'd also need rules about |
| 22 |
> conditionals so that the metadata cache works. |
| 23 |
Maybe this rule can be added: |
| 24 |
4. Stable ebuilds are never multiversioned. |
| 25 |
|
| 26 |
So once an ebuild get stable it is split out of the multiversion ebuild (aka copied) and not touched anymore. |
| 27 |
Maybe this rule can be smoothed by moving the split to the point where new features are introduced in the ebuild: |
| 28 |
4. If a multiversion ebuild contains a stable version and is changed featurewise (e.g. a new useflag), then the stable version is split out of the multiversion ebuild. |
| 29 |
|
| 30 |
I don't know the internals of the metadata cache, so I can't say something to that. |
| 31 |
|
| 32 |
|
| 33 |
> You also would need to be careful about ebuild revisions in general, since |
| 34 |
> you're potentially affecting multiple versions at the same time. |
| 35 |
You are right. But maybe it's the same fix, that is applied to all versions at once. |
| 36 |
|
| 37 |
> How would revbumps fit into this? All kinds of bad things can happen by |
| 38 |
> editing ebuilds in place, and this would compound the issue. |
| 39 |
Maybe it is possible to solve with the following method: |
| 40 |
1. If the fix affects all ebuild versions, revbump all versions in the ebuild. |
| 41 |
2. If the fix affects only one version, split out this version of the ebuild and make it an explicit one (together with the fix). |
| 42 |
|
| 43 |
The thing is that it is an additional concept. It does not replace the current mechanisms and at best reduces overhead for ebuilds that are identical. |
| 44 |
|
| 45 |
Gerion |
Archives