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. 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. If I remember correctly you are not comfortable with ebuilds like this and I'm not quite sure why. > > 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. Thanks, William > > -- > Best regards, > Michał Górny >
signature.asc
Description: PGP signature
