Summary: | dev-lang/php - php.ini type should be determined through a USE flag | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andreas <medic123> |
Component: | [OLD] Development | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | Lowest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=611214 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andreas
2014-11-21 00:43:50 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. >> 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 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. (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. 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. (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. |