Depot dependencies [was Re: Ticket #14796 (pike): please commit]
Jordan K. Hubbard
jkh at apple.com
Wed Apr 2 17:43:05 PDT 2008
[ Making another futile attempt to use a more descriptive subject line ]
On Apr 2, 2008, at 3:56 PM, Rainer Müller wrote:
> I think it is a horrible idea. It totally defeats the feature of
> having multiple versions of a port but only one active version.
Not at all. If you want to continue the notion of /opt/local then
there's still only one "active" non-colliding port permitted in there
at a time and you still have this "feature", for whatever it's worth,
and that's not much. See below:
> If you start linking into the depot, also rewrite all calls to
> binaries to the depot and all access to /opt/local/share and so on.
> Otherwise it would totally become inconsistent. And I don't
> understand why you want to look for such files inside the depot. The
> depot stores multiple versions and you activate one and only one of
> them - the others are inactive and not used at all.
That's the problem - the others are inactive and you might WISH that
they weren't used at all, but reality from an end-user's perspective
will not fulfill this wish for you. Users WILL want to be able to use
portX and portY simultaneously where each depends on a different
version of portZ, and expecting the portX and portY folks to converge
on a single version of portZ is about as practical as expecting
everyone in the middle east to stop fighting. It won't happen, you
can't force it to happen (well, you can try, but you'll quickly run
out of time and energy) and the best you can do is try and devise a
framework which allows it to happen in a controlled fashion.
> - If I deactivate a port, I *expect* depending ports to break.
You are talking like a developer, not a user. Users *expect* to use
what may be a large collection of software, all "activated" at the
same time, and they don't want to hear about how limitations in
cooperation / available time among software developers are keeping
them from having portX and portY active at the same time. After you
have listened to them complain for a couple of years, you won't want
to hear about it either.
MacPorts is still in the honeymoon phase where few actual "end users"
use it (largely due to the absence of pre-built packages and a GUI)
and the collection is small enough that these sorts of problems don't
happen very often. Do not, however, make the mistake of thinking that
just because it is not a problem for you, or a problem today, that it
is not going to be a problem in the future.
People are also free to not believe me - that's cool - I'm used to
that. Do, however, at least give me the courtesy of keeping in mind
the fact that I did create the FreeBSD Ports Collection and was in an
excellent position to watch it grow from 200 ports to 2,000 ports to
12,000 ports, observing a number of painful experiences and "gosh, if
we'd only done X, Y or Z at the start" lessons learned along the way.
When my group at Apple created DarwinPorts, we also tried to learn
from some of those lessons and create a more flexible ports framework,
but we didn't attempt to solve every problem we knew would be coming
in the future since we had only so much time and few resources. This
is one of the problems we didn't have time to solve but knew we'd need
to if DarwinPorts ever truly became a big success and had lots of
users. Maybe that lack of success has been a blessing in disguise,
but it hardly seems like something the project would want to aim for.
A system for developers and by developers isn't nearly as interesting
as trying to actually solve the hard problems.
More information about the macports-dev