| 1 |
On Mon, 2020-05-18 at 15:02 -0500, William Hubbs wrote: |
| 2 |
> On Mon, May 18, 2020 at 09:42:46PM +0200, Michał Górny wrote: |
| 3 |
> > Why would an ebuild have to check whether the ebuild is live? Isn't it |
| 4 |
> > supposed to know that by definition? |
| 5 |
> |
| 6 |
> See below where I talk about the ebuild version. |
| 7 |
> |
| 8 |
> > > The up side of this would be that we aren't reserving a specific version |
| 9 |
> > > number for live ebuilds. |
| 10 |
> > |
| 11 |
> > We aren't. |
| 12 |
> |
| 13 |
> In practice we basically do. If an ebuild has version number 9999, that |
| 14 |
> version is considered a live ebuild. |
| 15 |
|
| 16 |
...or *.9999, or 9999.* in some cases. All of them have one common |
| 17 |
property -- they're clear what they are and the user doesn't have to |
| 18 |
second guess what they might be. Well, except that one silly package |
| 19 |
where author used versions like 0.9999, 0.99999, 0.999999... |
| 20 |
|
| 21 |
> I suppose this brings up the question of one ebuild serving as release |
| 22 |
> and live ebuilds. |
| 23 |
> |
| 24 |
> I've written a number of ebuilds like this because it seems easier to |
| 25 |
> keep things in sync if you do this. I'm guessing others have done the |
| 26 |
> same also. |
| 27 |
|
| 28 |
Maybe it is, maybe it isn't. I've seen ebuilds lose changes because |
| 29 |
someone copied -9999 that was outdated. I've seen ebuilds lose keywords |
| 30 |
because someone decided it a good idea to keep keywords in -9999 |
| 31 |
and didn't tell arch teams about it. |
| 32 |
|
| 33 |
> The down side that is being pointed out to me right now is that |
| 34 |
> > > we would need a function like in_iuse, but called in_properties, to |
| 35 |
> > > check the properties. We would need something like this because |
| 36 |
> > > properties supports use conditionals, e.g. |
| 37 |
> > > PROPERTIES="foo? ( bar )" |
| 38 |
> > |
| 39 |
> > No, that's not why we needed in_iuse. We need IUSE because IUSE is |
| 40 |
> > stacked and there's no guarantee that its value will be correct (or even |
| 41 |
> > present) at an arbitrary time during ebuild execution. |
| 42 |
> > |
| 43 |
> > in_iuse does not handle USE conditionals because obviously there are |
| 44 |
> > none in IUSE. |
| 45 |
> > |
| 46 |
> > PROPERTIES isn't stacked at the moment but there is a proposition to |
| 47 |
> > make it stacked in EAPI 8 for better consistency. Right now it is easy |
| 48 |
> > to wrongly assume it is stacked and accidentally override it. |
| 49 |
> |
| 50 |
> Is RESTRICT part of that proposal? It would be nice to have it |
| 51 |
> stacked as well. |
| 52 |
> |
| 53 |
|
| 54 |
Yes [1]. |
| 55 |
|
| 56 |
[1]:https://bugs.gentoo.org/701132 |
| 57 |
|
| 58 |
-- |
| 59 |
Best regards, |
| 60 |
Michał Górny |
Archives