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

[Emmanuel Hainry]

Citando 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,

I certainly won't be a user of That macports.

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

What you are talking about is dependencies on version, not on inactive
ports. Dependency on version is useful on some cases, and its
implemented in macports (there's a workaround): some ports have more
than one version: libnet vs libnet11, the handful of db4x ports.
Depending on an inactive port is a nightmare: if you update a library,
you don't expect its dependents to still use the unsecure deprecated
one: users expect dependents to link against the new secure lib (no API
change) or the dependent ti be relinked...

The way to go in my mind is more to inform of an API change so that
dependents are rebuilt by default if needed.

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

The thing is we developpers (or people thinking like developpers) are
also users and we want things to work as expected and in a logical and
predictible way, not necessarily in a way that is the most comfortable.
I don't expect that many of us will want to be developpers of a project
we won't use, do you?

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

Last thing: the problem of dependents would greatly benefit from binary
builds as port maintainers would be able to test more easily if
dependents are breaking and thus to mark them for rebuild. But the way
it is now, the only thing that would be needed for users to be more
comfortable would be changing the default behaviour of upgrade and
solving the cycling when using recursive upgrade.

Emmanuel