Simple Question Why some package install dependencies already installed


I’m just installing emacs-head HEAD and was wondering why the formulae want to install a package that is already installed on my system.

Indeed, when installing emacs HEAD (27.x) with ImageMagick as an option (dependency), then version 7 of the later is needed and specified as imagemagick@7. On my system, I installed ImageMagick version 7 but the package name is imagemagick and not imagemagick@7. Both folders contain the same code and libraries…

I understand the purpose and in particular to guarantee that the package will be broken with future updates BUT 8u ago i decided to use brew because they were trying to use the libs on the system to avoid unneeded libs to be installed as it was the case with macports.

Is there a way to avoid those already installed libs to be installed again?

How did you install the other package?

λ brew desc -n /magick/
graphicsmagick: Image processing tools collection
imagemagick: Tools and libraries to manipulate images in many formats
imagemagick@6: Tools and libraries to manipulate images in many formats

As you can see, there are two versions, and the preferred one is 7.x.
Also, I don’t understand why your emacs build even asks for ImageMagick - I clearly see it disabled with --without-imagemagick.

It doesn’t depend on it actually, these must be local changes then.

brew deps emacs --include-build --tree                                                                                              •
├── pkg-config
└── gnutls
    ├── pkg-config
    ├── gmp
    ├── libtasn1
    ├── libunistring
    ├── nettle
    │   └── gmp
    ├── p11-kit
    │   ├── pkg-config
    │   └── libffi
    └── unbound
        ├── libevent
        │   ├── autoconf
        │   ├── automake
        │   │   └── autoconf
        │   ├── doxygen
        │   │   └── cmake
        │   │       └── sphinx-doc
        │   │           └── python
        │   │               ├── pkg-config
        │   │               ├── gdbm
        │   │               ├── openssl
        │   │               ├── readline
        │   │               ├── sqlite
        │   │               │   └── readline
        │   │               └── xz
        │   ├── libtool
        │   ├── pkg-config
        │   └── openssl
        └── openssl

to be clear I took emacs and imagemagick as one example among others. I installed imageMagick the normal way without referencing a particular version brew install imagemagick

and I wanted to have support for imagemagick in emacs so I took emacs-head since I don’t like the new concept used for installing emacs which does not offer option anymore.

So I installed with brew install emacs --with-imagemagick ....

--without-imagemagick is surely not an option since I wanted the support. And as you can see imagemagick@7 is missing from result set …

That’s why I do not use emacs homebrew because the way it is built is useless for me and got some complaints from other AFAIR … I want imageMagick Support in emacs and this how emacs is built

  def install
    args = %W[

and as one can see --without-imagemagick is explicitly used, Why the maitainer decides this, do not know, that’s why many uses emacs-head or -mac or -plus instead.

AND for this package, we have a dependency of imagemagick@6 or imagemagick@7 if --HEAD i.e. emacs 27. should be installed. And this is the issue why the maintainers are explicitly referring to a specific version I understand if the library is old but for the current version this should not be the case. As I said, I understand the maintainers but imao this breaks a little bit the spirit Homebrew had at the beginning, namely to reuse currently installed software and libs .

None of those are part of homebrew-core so I can’t really say anything about how those work as I almost exclusively use homebrew-core.

I don’t really understand the issue, imagemagick isn’t part of macOS afaik and imagemagick 7 is the latest version. So it does depend on the existing install of a recent version. If you installed tools manually and want those to be picked up thats a whole different story. Cause that case causes a ton of issues with builds and has therefore been disabled by default.

Yes, take e.g. the mongodb formula, which is part of homebrew-core, it uses this

 depends_on "python@2"

and currently, python V2 is the default installed python, still under Mojave. I understand that one wants to minimize the risk, but this formula will install python v2 (60MB). But the OS has a V2 installed so why not try to use this one since is the system default. This is how originally brew was designed and was appealing (exactly as were the macports before they also introduced version dependencies and now when installing a macport it clutters the disk with all its dependencies)

My post is not about trolling or whatever, only to remind the maintainers to try as most as possible to persist the spirit of brew which is/was, use the libraries available on the system, either default
or installed using brew. And this should respond to your second answer

I know that imagemagick isn’t part of macOS. The idea I try to explain is that, taking emacs-head as an example to make HEAD dependent on imagemagick (as done mostly in homebrew-core, also not on a particular version) and to use imagemagick@6 for emacs26, i.e. non-HEAD option, only if the current version of imagemagick breaks emacs runtime. Best would be that theaLib@version really packs as little as possible into the dependent formula

But anyhow thanks you to all of you investing time and efforts for maintaining the software we all use on a daily basis.

In my experience builds usually break when you use the system python for unknown reasons. If you can find a way where it works reliably on macOS, by all means make a PR to remove the dependency.

Everyone seems to have their own about what brew is, and in my mind the usability of brew is infinitely more important than the saved diskspace.

I still don’t understand what you want with this. Dependencies are only ever added if they’re useful for the majority of users. This is either because it breaks otherwise (majority/all want working software) or because it’s missing an important part.