Depot dependencies [was Re: Ticket #14796 (pike): please commit]

[Jordan K. Hubbard]

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

- Jordan