Skip to content
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

Closed
wants to merge 4 commits into from
Closed

php: Fully version the pear repository #26137

wants to merge 4 commits into from

Conversation

kabel
Copy link
Contributor

@kabel kabel commented Apr 4, 2018

  • Have you followed the guidelines for contributing?
  • Have you checked that there aren't other open pull requests for the same formula update/change?
  • Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
  • Does your build pass brew audit --strict <formula> (after doing brew 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 to HOMEBREW_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 run brew post-install php, I can add in revisions.

This addresses #26108 and ensures fixes #25974.

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilovezfs
Copy link
Contributor

ilovezfs commented Apr 4, 2018

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 run brew post-install php, I can add in revisions.

yeah sounds like it's worth revision bumping

@ilovezfs ilovezfs added the php PHP use is a significant feature of the PR or issue label Apr 4, 2018
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}"
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@SMillerDev
Copy link
Member

@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)

@ilovezfs
Copy link
Contributor

ilovezfs commented Apr 5, 2018

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 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 HOMEBREW_PREFIX/"share/pear" is nicer than HOMEBREW_PREFIX/"share/pear-latest"

@kabel
Copy link
Contributor Author

kabel commented Apr 6, 2018

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)

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?
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this re-runnable?

Copy link
Contributor Author

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).

@westberliner
Copy link

Tested this change request today. Worked for me. Hope, that it will be merged soon.

@ilovezfs
Copy link
Contributor

@kabel #26298 is now merged. Please rebase this on master when you have a chance, and make it one commit per formula. Thanks!

kabel added 4 commits April 11, 2018 20:34
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.
@ilovezfs ilovezfs closed this in 09dc59d Apr 12, 2018
@ilovezfs
Copy link
Contributor

Thanks @kabel 🚀

@kabel kabel deleted the php-version-pear branch April 22, 2018 23:03
Neodork added a commit to tamtamnl/valet-plus that referenced this pull request Apr 26, 2018
samgranger pushed a commit to weprovide/valet-plus that referenced this pull request Apr 30, 2018
@lock lock bot added the outdated PR was locked due to age label May 22, 2018
@lock lock bot locked as resolved and limited conversation to collaborators May 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated PR was locked due to age php PHP use is a significant feature of the PR or issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot brew link --force [email protected] out of the box
6 participants