This repository has been archived by the owner. It is now read-only.

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

Closed
mistydemeo opened this Issue Aug 9, 2012 · 17 comments

Comments

Projects
None yet
9 participants
Contributor

mistydemeo commented Aug 9, 2012

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.

Owner

MikeMcQuaid commented Aug 9, 2012

Sounds good.

Contributor

jacknagel commented Aug 10, 2012

Agreed

Member

mxcl commented Aug 10, 2012

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.

Member

mxcl commented Aug 10, 2012

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.

Contributor

staticfloat commented Aug 10, 2012

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

Member

mxcl commented Aug 31, 2012

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

Contributor

staticfloat commented Dec 3, 2012

EDIT: Discussion removed and placed into mxcl#16375

Contributor

samueljohn commented Dec 3, 2012

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

Contributor

staticfloat commented Dec 3, 2012

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

Contributor

mcg1969 commented Mar 29, 2014

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.

Contributor

mcg1969 commented Mar 29, 2014

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 Apr 4, 2014

Contributor

jacknagel commented Apr 4, 2014

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

Contributor

mcg1969 commented Apr 4, 2014

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.

Contributor

samueljohn commented Apr 4, 2014

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

Contributor

dpo commented Apr 4, 2014

@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 Apr 27, 2014

@jacknagel jacknagel removed the help wanted label May 16, 2014

Contributor

NikolausDemmel commented Aug 1, 2014

@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 added this to the New dependency implementation milestone Nov 3, 2014

@jacknagel jacknagel removed their assignment Nov 26, 2014

Owner

MikeMcQuaid commented May 28, 2016

Now that every formula is in a tap: I think this no longer applies.

@MikeMcQuaid MikeMcQuaid locked and limited conversation to collaborators Jul 11, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.