Bug 530002 – dev-lang/php - php.ini type should be determined through a USE flag

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Andreas 2014-11-21 00:43:50 UTC]

Hi,
I just emerged PHP and was confronted with:


 * Make sure that PHP_TARGETS in /etc/make.conf includes php5-5 in order
 * 
 * You can chose which version of php.ini to install by default by setting PHP_INI_VERSION to either
 * 'production' or 'development' in /etc/make.conf


Do we really want to misuse make.conf for that?
Do we want (all) Gentoo-Packages to use make.conf for their specific configuration?

I thought, thats what USE-flags are for.

What kind of config shall be used is certainly a USE-flag, isn't it?

Cant speak of "what kind of ABI" to use, if this is worth a make.conf flag, but I personally don't like the way dev-php/php goes here.

bests
Andreas

[Comment 1 Jeroen Roovers (RETIRED) 2014-11-21 09:03:13 UTC]

(In reply to Andreas from comment #0)
>  * Make sure that PHP_TARGETS in /etc/make.conf includes php5-5 in order
>  * 
>  * You can chose which version of php.ini to install by default by setting
> PHP_INI_VERSION to either
>  * 'production' or 'development' in /etc/make.conf
> 
> Do we really want to misuse make.conf for that?

What do you suggest we use instead for the local configuration of ebuilds?

> Do we want (all) Gentoo-Packages to use make.conf for their specific
> configuration?

Er, yes?

> I thought, thats what USE-flags are for.

Don't you set those in make.conf as well? Again, where else would you want it to be done?

> What kind of config shall be used is certainly a USE-flag, isn't it?

USE flags enable/disable build-/install-time features in a strictly binary way. If you want more than two things, you can combine USE flags or just check a well-known variable to be set.

[Comment 2 Andreas 2014-11-21 12:13:45 UTC]

>> Do we really want to misuse make.conf for that?
> What do you suggest we use instead for the local configuration of ebuilds?

for systemwide configurations make.conf, for package specific configs "package.use"?
But as you noticed yourself, I disagree with the "import" of "package specific" variables into make.conf. 

>> Do we want (all) Gentoo-Packages to use make.conf for their specific
>> configuration?
>Er, yes?

Errr, no?  
read "specific", not "systemwide". I really love the slim design of configuration of Gentoo - it's like portage a great Idea, implemented in a  good way. 
For "specific" Configurations we have package.use.

I completely agree with systemwide configuration shall be  in make.conf. 
I completely agree that the decision if "production" or "develpment" is a specific or systemwide configuration can be argued about.

> USE flags enable/disable build-/install-time features in a strictly binary way. 
> If you want more than two things, you can combine USE flags or just check a 
> well-known variable to be set.

And thats a great feature. You can combine them, or force decision via any-of.
No need to "officially introduce sophisticated variables" into such a good design.
As you probably know, "because it works" sometimes is not the best idea.

bests
Andreas

[Comment 3 Michael Orlitzky 2016-12-03 03:44:57 UTC]

To clarify Jeroen's point:

The PHP_INI_VERSION variable currently only has two possible values, but semantically it's a list of arbitrary length that only happens to contain two items at the moment.

The choice of INI file is not a compile-time flag; instead, upstream ships "several" different INI files. For now, "several" is "two":

  * php.ini-production
  * php.ini-development

but it is conceivable that one day

  * php.ini-testing

might show up.

Right now, we could have USE=production, and that would unambiguously determine which ini file to use. However, if a third option ever shows up, the USE flag strategy goes to hell, and you have to start combining the flags in awkward ways to indicate the particular option you want.

For that reason, I think the special variable PHP_INI_VERSION is still the best way to do this.

[Comment 4 Michael Orlitzky 2016-12-03 04:03:33 UTC]

(In reply to Michael Orlitzky from comment #3)
> 
> For that reason, I think the special variable PHP_INI_VERSION is still the
> best way to do this.

Why not argue with myself...

If we wanted to do this, we would need to add two new flags (for example):

  * ini-production
  * ini-development

To ensure that exactly one of them is set, we would need to add

  REQUIRED_USE="^^ ( ini-production ini-development )"

But then we'd need to set a default...

  IUSE="... +ini-development ..."

That isn't too bad, even though it makes you explicitly disable the default USE flag if you want to set the non-default one. I guess the part of it that seems off to me is that it encodes one bit of information in two bits. And when all of the flags are yes/no, we have to check them one-at-a-time in the ebuild:

  if use ini-production; then blah blah php.ini-production; fi
  if use ini-development; then blah blah php.ini-development; fi
  if use ini-testing; then blah blah php.ini-testing; fi

whereas now we have the piece of info that we want right in the variable:

  blah blah php.ini-${PHP_INI_VERSION}

I guess you could avoid some of that by putting all of the ini-* USE flags in a variable and then looping over it, but it probably wouldn't save any /space/.

Of course one benefit is that you could then install the development ini file for php:7.1 while keeping the production one for php:5.6.

[Comment 5 Michael Orlitzky 2017-02-28 14:38:44 UTC]

Here's an idea: since the difference between the development and production INI files amounts to... five lines? Why don't we just get rid of the whole thing and install the production ini file unconditionally. It will make things a lot simpler.

[Comment 6 Michael Orlitzky 2017-03-21 19:32:56 UTC]

(In reply to Michael Orlitzky from comment #5)
> Why don't we just get rid of the whole thing and install the production
> ini file unconditionally. It will make things a lot simpler.

This is done in the latest three revisions.