On Mon, 2020-05-18 at 15:02 -0500, William Hubbs wrote: > On Mon, May 18, 2020 at 09:42:46PM +0200, Michał Górny wrote: > > Why would an ebuild have to check whether the ebuild is live? Isn't it > > supposed to know that by definition? > > See below where I talk about the ebuild version. > > > > The up side of this would be that we aren't reserving a specific version > > > number for live ebuilds. > > > > We aren't. > > In practice we basically do. If an ebuild has version number 9999, that > version is considered a live ebuild.
...or *.9999, or 9999.* in some cases. All of them have one common property -- they're clear what they are and the user doesn't have to second guess what they might be. Well, except that one silly package where author used versions like 0.9999, 0.99999, 0.999999... > I suppose this brings up the question of one ebuild serving as release > and live ebuilds. > > I've written a number of ebuilds like this because it seems easier to > keep things in sync if you do this. I'm guessing others have done the > same also. Maybe it is, maybe it isn't. I've seen ebuilds lose changes because someone copied -9999 that was outdated. I've seen ebuilds lose keywords because someone decided it a good idea to keep keywords in -9999 and didn't tell arch teams about it. > The down side that is being pointed out to me right now is that > > > we would need a function like in_iuse, but called in_properties, to > > > check the properties. We would need something like this because > > > properties supports use conditionals, e.g. > > > PROPERTIES="foo? ( bar )" > > > > No, that's not why we needed in_iuse. We need IUSE because IUSE is > > stacked and there's no guarantee that its value will be correct (or even > > present) at an arbitrary time during ebuild execution. > > > > in_iuse does not handle USE conditionals because obviously there are > > none in IUSE. > > > > PROPERTIES isn't stacked at the moment but there is a proposition to > > make it stacked in EAPI 8 for better consistency. Right now it is easy > > to wrongly assume it is stacked and accidentally override it. > > Is RESTRICT part of that proposal? It would be nice to have it > stacked as well. > Yes [1]. [1]:https://bugs.gentoo.org/701132 -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
