A Plea to Reduce Dependences

[Anders F Björklund]

Arno Hautala wrote:

>> Fink only has one tree now (called "stable"), for lack of resources...
> 
> Really? That's interesting. Without dragging this thread too far off
> track, did they just merge the trees? Or, just drop support for
> unstable?

They renamed the "unstable" branch to "stable", when copying things over
from the 10.5/10.6 tree (called 10.4). Presumably for marketing reasons.

http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/    (Leopards)
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/    (Lions)

The old (unsupported) tree for Mac OS X 10.4 was renamed to "10.4-EOL",
when the symlink from 10.6 to 10.4 was made. (over in /sw/fink that is)

The 10.5/10.6 tree and the 10.7 tree are totally separate entities,
instead of having "darwin 10" and "darwin 11" platform { } blocks.

>> But how many trees are available isn't limited with either system ?
> 
> My understanding is that MacPorts doesn't have the concept of trees as
> much as it supports an arbitrary number and location of trees that are
> merged together. I think that Fink required switching between stable
> and unstable, I don't remember if or how one could include an
> arbitrary tree with the current selection. Meh, details.

For both systems, you set which tree up in your configuration...

/opt/local/etc/macports/sources.conf:
#rsync://rsync.macports.org/release/tarballs/ports.tar [default]
rsync://rsync.macports.org/release/ports/ [default]

/sw/etc/fink.conf:
#Trees: local/main stable/main stable/crypto
Trees: local/main unstable/main unstable/crypto

Whether you call it "release" or "stable" doesn't really matter ?

>> Both MacPorts and Fink do use _some_ system resources, and Homebrew
>> does allow _some_ dupes, so it's a rather fuzzy difference all around.
> 
> True, I was going more for the philisophical goals rather than the
> gritty details.

Just saying that the differences might be smaller than you think,
at least when it comes to actual packaging and their interaction.

The /usr/local versus /opt/local is a big difference, but then
again MacPorts also started out in /usr/local in the beginning
and you don't really _have_ to use the default prefix in Homebrew.
Using and allowing bin: and lib: has also changed over the years.

Some more major philosophical differences do exist, though:

* Homebrew doesn't allow modules for Python/Perl/Ruby as ports,
  which means that those are excluded from the (managed) depends.

* Homebrew doesn't allow things that build .app bundles, but
  prefer command-line tools - or X11 if you absolutely have to.

* Homebrew doesn't use summaries or descriptions, but refer to
  the software homepage (which is _required_) for information.

* Homebrew doesn't have revisions and tries to avoid patches,
  preferring/requiring everything to go upstream (if possible).

Otherwise it's more similar than different, at least to me ?

The most readily apparent difference is the project's age, which
affects both language (Ruby vs Tcl/Perl) and VCS (git vs svn/cvs)

>> The main difference is that you can install the packages without
>> needing the rest of the build system and ports/formula sources,
>> there was some talk about such a feature for MacPorts as part of
>> the Google Summer of Code projects - but it didn't happen...
> 
> Ah, true. That's still a good goal.

Also kinda pointless, if the regular MacPorts can do it with the
port -b flag - then the main difference is needing the ports tree.

At least if the "pkg" tool still has to parse through the Portfiles,
instead of just reading some available package metadata information.

>> But you can (soon?) use it without Xcode, which is "good enough" ?
> 
> Another (upcoming?) feature I didn't know about. I need to subscribe
> to the VCS feed or idle on IRC more.

You need Xcode to build stuff. If things are already built, you only
need Tcl (for portfiles) and Tar (for archives). At least in theory.

It's not (yet?) supported, so you need the enormous-but-free Xcode.
But to be fair, most of that installer size comes from the iOS SDK...

--anders