Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Depending on a tapped formula without the full path shouldn't be possible #14089

Open
mistydemeo opened this Issue · 16 comments

9 participants

@mistydemeo
Owner

Currently, we allow a formula to depends_on a tapped formula without specifying the repo name. This has the potential to encourage taps to do some confusing stuff that's hard for end-users to debug.

For instance, php53 and php54 in josegonzalez/php used to depend on an unqualified zlib - which only worked for users with homebrew/dupes tapped, since neither mxcl/homebrew nor josegonzalez/php include a zlib. This was reported by a user in IRC when brew upgrade failed with confusing error messages.

Suggestion: depends_on should not allow unqualified names when called with a tapped formula, unless the formula being depended on comes from the same tap. While I'm -1 on the added complexity, inadvertently allowing third-party taps to do Bad Things seems like it's setting the stage for more confusion.

@mikemcquaid
Owner

Sounds good.

@jacknagel
Owner

Agreed

@mxcl
Collaborator

No, actually, I disagree, although I opened this same ticket not so long ago, I closed it.

Basically: yes our support burden goes up, but this is how it should be.

If a tap removes a formula, the user should be able to get it from somewhere else and have dependencies satisfied. This is currently how the (badly designed) install from URL system works.

I believe a possible solution is to recommend a tap in the depends_on string and if the build fails tell the user that they are doing something unsupported.

More rationale: this is how debian etc work, you can get a package from anywhere and use it provided it satisfies other criteria. I frequently broke my system with bad packages.

@mxcl
Collaborator

We should improve the related error messages. We can suggest the user does a search. Formula can exist elsewhere now and we need to make users aware that tapped formula may depend on taps they don't have.

Obv. mxcl/master formula should fully reference dependency taps.

But stuff in other taps should be allowed to be more vague. We just have to error out CORRECTLY and try to convince idiot-users not to report the bugs to us.

@staticfloat

"Obv. mxcl/master formula should fully reference dependency taps."

I thought that mxcl/master Formulae shouldn't have external dependencies at all?

Additionally, it seems "best practice" to me to ask Formula authors to document (either in code or comments) where their dependencies come from. Having it in code gives the option of having HB spit information out at users.

@mxcl
Collaborator

I guess we can force explicit tap paths and then try to find another formula if that tap doesn't have the formula anymore.

@staticfloat

EDIT: Discussion removed and placed into #16375

@samueljohn

@staticfloat your issue is somewhat related but not what @mistydemeo described (I think). Therefore, I vote for a separate bug report - as that can be fixed quicker and independently of this suggestion.

@mistydemeo suggests that tapped formulae have to use the full qualified name, such as depends_on "staticfloat/julia/openblas". I am -0 on this.

But your issue @staticfloat is: Even if you do specify the full qualified name, homebrew seems to pick up the first formula named "openblas" and - even worse - ignores if the user has manually installed brew install staticfloat/julai/openblas and re-installes the other openblas.

@staticfloat

Alright. I have opened a new issue and cleaned out my above comment. #16375

@mcg1969

The new homebrew/science/octave recipe candidate is now borking because of inconsistent references to OpenBlas. Octave is actually a good example of why it is important that a consistent convention be employed here, because it depends on a large number of packages that all require some sort of BLAS capability. It has been difficult enough to get them to all agree on how to link to vecLib properly!

I don't agree that a full pathname should be required (EDIT: see below). But what seems clear is that unless full pathnames are required for all dependencies, then they should never be used to refer to a recipe from the same tap.

What's funny is that there really isn't an ambiguity here. As far as I can tell, there is only one OpenBLAS, and it's in homebrew-science.

@mcg1969

Actually I misread @mistydemeo's post. If I understand it correctly I agree with her. That is, a fully qualified name to a tapped formula should be required, unless the calling formula is itself in the same tap.

@jacknagel jacknagel self-assigned this
@jacknagel
Owner

I'm going to spend some time on this over the weekend.

As far as I can tell, the rules we want are:

  • if a dependency is fully-qualified, it can only be satisfied by that specific tap.

  • if a dependency is not fully-qualified, we first try to find it in the formula's tap, then in core. Other taps cannot satisfy the dependency.

Is this correct? Will this resolve the existing problems?

/cc @samueljohn @dpo @mcg1969

@mcg1969

That sounds great. If that also ensures that the dependency resolver can recognize the equivalency of unqualified and qualified pointers to the same formula, then this would indeed fix the problems we're seeing with OpenBLAS.

@samueljohn

@jacknagel perfectly. Internally brew should perhaps always work by first attempting to transform into fully qualified names exactly as you propose. Thanks for doing this.

@dpo
dpo commented

@jacknagel Many thanks. The rules you propose sound right. I thought that if a dependency isn't found in the formula's tap or in core, the "official" taps could also be searched. This would reduce usage of full qualified names to "unofficial" taps (i.e., externally maintained).

@jacknagel jacknagel added deps and removed usability labels
@jacknagel jacknagel removed the help wanted label
@NikolausDemmel

@jacknagel: Regarding your comment on how you want to implement this.

I have a patched cmake formula in nikolausdemmel/devel/cmake. I have installed that manually instead of the cmake formula from core with brew install nikolausdemmel/devel/cmake. Currently, all fomulae depending on cmake are happy to accept this patched install to satisfy the dependecy.

Does you proposal mean that when this change is implemented this would not be possible any more?

@jacknagel jacknagel removed their assignment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.