| 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 |
Archives