-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
php: Fully version the pear repository #26137
Conversation
Formula/php.rb
Outdated
@@ -70,6 +70,9 @@ def install | |||
ENV.append "CPPFLAGS", "-DU_USING_ICU_NAMESPACE=1" | |||
|
|||
config_path = etc/"php/#{php_version}" | |||
# Prevent system pear config from inhibitting pear install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're pouring a bottle, isn't this still a concern? Should we handle it in post_install?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, It's only build time. post_install rebuilds it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only one "t" in the word "inhibiting"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah sounds like it's worth revision bumping |
Formula/php.rb
Outdated
@@ -218,7 +222,7 @@ def post_install | |||
php_ext_dir = opt_prefix/"lib/php"/php_basename | |||
|
|||
# fix pear config to install outside cellar | |||
pear_path = HOMEBREW_PREFIX/"share/pear" | |||
pear_path = HOMEBREW_PREFIX/"share/pear@#{php_version}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to version the main unversioned formula? That typically ends up meaning that we then need to provide automatic migration when e.g. this gets upgraded to 7.3.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it mean the opposite as in if the files are attached to the version itself rather than the latest version it would make more sense ? Otherwise we would have to migrate when the version switches from 7.2 to 7.3 which potentially could break things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing files stop working when php is upgraded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're probably right, I mixed it up with the compiled binaries but they are stored elsewhere. The pear directory only contains the pear php code so it should be reasonably portable between versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine if we want the user controlled repository to be compatible with the next major/minor release--although we already have the issue that the versioned config php.ini
doesn't migrate forward. Do you have a suggestion as the the suffix to use? The path without a suffix will always be the repository that upstream installs to make the pear and pecl commands work, and we don't want to conflict with the linked files.
@kabel what's your opinion on ensuring that the extension_dir setting in php.ini is correct? (replacing it with the new path for people who only upgraded) |
@kabel Can we relocate the linked files instead of linking them to avoid the redundancy? For example, we could stash them somewhere in pkgshare and then copy them over in post install. I think |
I'd be okay with maybe putting a warning in post_install, but I'm leery of trying to manage user configuration. |
@@ -70,6 +71,9 @@ def install | |||
ENV.append "CPPFLAGS", "-DU_USING_ICU_NAMESPACE=1" | |||
|
|||
config_path = etc/"php/#{php_version}" | |||
# Prevent system pear config from inhibiting pear install | |||
(config_path/"pear.conf").delete if (config_path/"pear.conf").exist? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be wary of deleting user files here. Additionally, bear in mind this won't work for bottled installs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit wary, but pear has a two-tier configuration system that provides a "system" config and a "user" config. Users should not be modifying the system config and the post_install will rebuild it. The guard is there specifically for source builds, as anyone that has this config file with configuration pointed at a pear repository where the pear files are already installed will skip the pear installation of binaries in the cellar. The would mean build from source upgrades would be missing the pear
and pecl
binaries.
@@ -219,6 +224,7 @@ def post_install | |||
|
|||
# fix pear config to install outside cellar | |||
pear_path = HOMEBREW_PREFIX/"share/pear" | |||
cp_r pkgshare/"pear/.", pear_path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this re-runnable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is. I've run it quite a few times in testing just to make sure that it didn't override manually installed things and keeps the upstream installed files in sync. Of course more robust testing from other users would be greatly appreciated (we all know what works4me gets).
Tested this change request today. Worked for me. Hope, that it will be merged soon. |
A shared version is still possible with user configuration, but we should follow the versioned policies to avoid link problems between versions.
A shared version is still possible with user configuration, but we should follow the versioned policies to avoid link problems between versions.
A shared version is still possible with user configuration, but we should follow the versioned policies to avoid link problems between versions.
A shared version is still possible with user configuration, but we should follow the versioned policies to avoid link problems between versions.
Thanks @kabel 🚀 |
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install <formula>
)?To more closely follow the Homebrew acceptable versioned formulae policies and to reduce issues with installing packages through pear/pecl, the pear repository has been separated for each version. The main pear packages (that are installed by upstream) will remain in the
share/"pear"
formula path, and be linked toHOMEBREW_PREFIX/share/pear
on link, and should not interfere with anything else.User's will retain the ability to use a single repository for all versions, via
pear set-config
.This does not address any repositories that were already created and modified by previously running and pear/pecl maintenance commands, and users may be required to manually remove some files from
share/"pear"
formula path for any version they installed packages to.I didn't bump the revision because it doesn't change the bottle/binaries. If we want people to get it without having to manually runbrew post-install php
, I can add in revisions.This addresses #26108 and ensures fixes #25974.