Breaking long dependency chains

[Freek Dijkstra]

Hi,

I've been a long MacPorts user, and tried my best to contribute to a few
ports.

One of the reasons I see people moving away to package managers like
Homebrew is that they don't like the many dependencies that come with
MacPorts.

I've seen the MacPorts users respond with the very valid remark that
MacPorts has a good reason to use its own libraries.

However, that is not the main issue. The fact remains that there are
many MacPorts packages with more dependencies than what is strictly
required.

I recall a thread from October 2008, where someone was surprised by the
depencies of rubber, a small Python script for compiling LaTeX
documents. At that time it has 142 dependencies. I just re-checked. It
now has 168 dependencies, including Perl, subversion, openssl, xorg.

DO run "port rdeps rubber" and ask yourself "do all these tools really
need to be installed before rubber works reliably?"

Of course, they is NOT required. Many of dependencies are completely
unnecessary.

There are a few reasons why these dependencies are installed nevertheless:

* If a dependency is installed, it automatically uses the default
variant. In the above example, gtk2 uses the x11 variant, and the
tex-live uses the doc variant, which increase the number of dependencies
dramatically.

* If X depends on Y, and Y depends on Z, it does not mean that X depends
on Z. X may only use a subset of the features of Y which does not require Z.

How to solve this? Frankly, I don't know. But I do feel we need to give
this problem a bit more attention.

Some suggestions:
* Reduce the number of dependencies. A good example is Python, which no
longer depends on GTK (it is no longer required to specify the
no_tkinter variant)
* Pick the least inclusive variant by default. In particular, do not
include gtk or x11 dependencies if not required.
* Break dependency chains for a few common culprits, even it that
requires some hard work in splitting packages. That includes stuff like
xmlto, gtk2,

While the above may give a short-term solution, it will mean people will
bump into variant problems (replacing one variant with another variant
is error-prone in my experience, if only because there are no automated
tools in place to test this).

Let me think out-of-the box here.
* Keep track of manually installed and automatically installed packages.
This ensures that it easier to start over, and that no
no-longer-required dependencies remain installed

* provide binary packages for a few packages that are installed
all-the-time. This includes perl, python, xorg.

* do depend on Mac-based tools for fetch dependencies and (in some
cases) build dependencies. While I do think that MacPort should build
its own library (e.g. openssl, perl version, etc.), I do not think that
it should build its own tools. E.g. Port uses the Apple-provided
/usr/bin/tclsh. Why would netpbm need to *compile* subversion just to
*fetch* netpbm?


The reason I bring this up is that I found that debugging gets harder
because of the many dependencies -- I recently had some troubles with
Python, but found myself not having the time to submit a bugreport
because it required me to reinstall all packages that depend on Python
-- that is, about 150 packages in my case. Doing that takes too long, so
I just moved on (in my case: forget about MacPorts and install Debian
with VirtualBox -- installing a new OS was in this case literally faster
than updating one MacPorts package. ouch.)



Below are a few dependency chains where I question it's validity.
(the fact that most examples start with texlive is not because I
question that package; it just happen to be a package with many
dependencies)


texlive-bin
  pkgconfig
    glib2
      perl5
        ...

texlive-bin
  xorg-libXaw
    groff
      ghostscript
        xorg-libXext
          xorg-libX11
            xorg-libxcb
              xorg-xcb-proto
                python27
                  ...

texlive-bin
  libzzip
    xmlto
      coreutils
        autoconf
          perl5
            ...

texlive-bin
  poppler
    gtk2
      atk
        gtk-doc
          gnome-doc-utils
            py27-libxml2
              python27
                ...

texlive-bin
  poppler
    gtk2
      pango
        cairo
          xrender
            xorg-libX11
              xorg-libxcb
                python27
                  ...

texlive-bin
  xorg-libXaw
    groff
      netpbm
        subversion
          ...

Regards,
Freek Dijkstra