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

Recommended dependencies should not be installed during upgrade and not be shown as missing. #4769

Closed
mfriedenhagen opened this issue Aug 28, 2018 · 9 comments
Labels
outdated PR was locked due to age

Comments

@mfriedenhagen
Copy link

  • I usually do not use brew to install docker as I am using the vendor's edge channel, which e.g. includes a local Kubernetes feature.
  • Now when installing gitlab-runner, docker is marked as a recommended dependency, so I installed gitlab-runner with brew install --ignore-dependencies gitlab-runner.
  • However, now I may not run simply brew upgrade, as a workaround I do the following:
#!/bin/sh -e
brew uninstall gitlab-runner || true
brew upgrade
brew install --ignore-dependencies gitlab-runner
brew cleanup
  • Another problem: when I run brew doctor or brew missing I still get warnings.
  • I would expect brew to ignore recommended but not strictly needed dependencies.
  • I could use gitlab-runner even in shell runner mode where I would not need docker at all.

So my proposal would be that brew somehow offers something like --ignore-recommended and stores this information somehow. I then expect:

  1. Running brew upgrade does not override my decision.
  2. brew doctor and brew missing do not complain about my decision.

For gitlab-runner alone, I could submit a PR to remove docker as dependency, however I could imagine that this is not the only formulae with a problem like this. 240 formulas in homebrew-core have recommended dependencies.

@MikeMcQuaid
Copy link
Member

brew install --ignore-dependencies gitlab-runner

This is not a supported workflow. We do not wish you to simply omit dependencies. In this case you can brew install --without-docker but it's likely this option will go away in future (Homebrew/homebrew-core#31510). My suggestion would be to simply ignore the docker that Homebrew installs and continue to use the vendor provided one.

@mfriedenhagen
Copy link
Author

This is unfortunate as at least the vendor package for docker installs symlinks into /usr/local/bin as well.

@mfriedenhagen
Copy link
Author

@MikeMcQuaid, I do not want to ignore-dependencies but as I said ignore-recommends as outlined in my proposal. Why is there a distinction between hard and recommended dependencies otherwise?

@MikeMcQuaid
Copy link
Member

@mfriedenhagen Please reread the command I recommended in my reply.

@mfriedenhagen
Copy link
Author

Hello @MikeMcQuaid,

  • first of all thanks for the quick answers (and for Homebrew in General) and please accept my apologies should I have sounded rude.
  • I indeed did execute brew install --without-docker gitlab-runner firstly as suggested by you.
  • Then gitlab-runner was not downloaded as bottled but built freshly from the sources.
  • At least in this case compiling is needless as docker is not a compile dependency, even the executable is not invoked but gitlab-runner may be configured to communicate via REST with a running docker-daemon. (Following this logic, nginx could be a recommended dependency of lynx 😁 )
  • Maybe I am just confused because recommended sounds like the option for Debian packages, for my non-native German ears it rings the same bell as "optional".
  • I did spend quite some time looking through web search results but could not find a definition but after looking at comments in brews source I am still confused:
    • Should depend_on only be given for stuff needed during build time and those which are recommended or optional change the produced binary?
    • What would then be the difference between [:optional, :build] and :optional?

Maybe non build relevant dependencies should be dropped at all?

@MikeMcQuaid
Copy link
Member

please accept my apologies should I have sounded rude.

No need to apologise but thanks anyway ❤️

but built freshly from the sources.

I'm afraid this is currently unavoidable.

Should depend_on only be given for stuff needed during build time and those which are recommended or optional change the produced binary?

No, it'll need to stay as it is now, sorry.

Maybe non build relevant dependencies should be dropped at all?

There's certainly an argument for it being removed in this case and added e.g. to caveats instead. @Homebrew/core thoughts?

@sjackman
Copy link
Member

If gitlab-runner does not require docker for either brew install gitlab-runner or brew test gitlab-runner to succeed, then I'm in favour of dropping that dependency.

@zbeekman
Copy link
Contributor

After having perused the requirements and install documentation for gitlab-runner, I see no reason to have depends_on "docker" => :recommended. This is enabling an optional feature, and the installation procedure does not change whether or not docker is installed, AFAICT. If we're taking away optional deps in the future, then I think a caveat would be fine here.

FWIW, the recommended macOS gitlab-runner installation technique is to just grab the latest go binary via curl. I strongly suspect, but have not personally tested, that a gitlab-runner installation will be able to use docker whether or not it was present on the system during the build.

My vote is to drop this from a recommended dep and possibly add a caveat.
I can look into testing my hypothesis RE being able to use docker in a bit. A caveat may not even be warranted here.

@commitay
Copy link
Contributor

IIRC several formulae have a docker dep that isn't needed at build time, opened Homebrew/homebrew-core#31582

@lock lock bot added the outdated PR was locked due to age label Sep 28, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Sep 28, 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
Projects
None yet
Development

No branches or pull requests

5 participants