1 |
On Wed, 2020-09-16 at 08:18 +0200, Ulrich Mueller wrote: |
2 |
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote: |
3 |
> |
4 |
> > +- one or more ``<version/>`` elements, each containing a version |
5 |
> > + constraint in the format matching EAPI 0 dependency specification |
6 |
> > + with the package category and name parts omitted, e.g. ``<1.7``. |
7 |
> |
8 |
> That's not a very powerful syntax, so unless I miss something, |
9 |
> metadata.xml would have to be updated for almost every stable candidate. |
10 |
> |
11 |
> To give an example, released versions of app-editors/emacs have exactly |
12 |
> two numerical components, while prereleases and release candidates have |
13 |
> three components or are marked _rc. Both would be impossible to match |
14 |
> with the proposed syntax. |
15 |
|
16 |
It's not 'one size fits all'. It will work for a number of packages, |
17 |
e.g. XFCE without too frequent updates. In the end, it's primarily |
18 |
designed around 'silencing' StableRequest results once they are |
19 |
reported, i.e. for packages that have long-ish RC periods. |
20 |
|
21 |
> So IMHO this has no advantage over keeping the information in the ebuild |
22 |
> (e.g. as a PROPERTIES token). |
23 |
> |
24 |
|
25 |
It has two advantages: |
26 |
|
27 |
1. It reduces the risk of accidentally leaving it in the stable ebuild. |
28 |
|
29 |
2. It handles specifying multiple stabilization candidates on different |
30 |
branches. I don't see how ebuilds would do that. |
31 |
|
32 |
-- |
33 |
Best regards, |
34 |
Michał Górny |