How image installs work [was Re: The image question]

[Daniel J. Luke]

On Mar 10, 2007, at 11:42 AM, Jordan K. Hubbard wrote:
> On Mar 10, 2007, at 8:04 AM, Daniel J. Luke wrote:
>>> You'd prefer that burden be foisted on the users, eh?  Those who  
>>> are perhaps least qualified to diagnose and fix the problem? :-)
>>
>> Or who are perhaps most qualified to make intelligent choices of  
>> what should be installed and upgraded at which time on their own  
>> systems? :)
>
> I wish this were true, but it's not.  Users who are that  
> intelligent already don't use macports (or fink) because they don't  
> need their hands held to any degree and already know where to find  
> what they're looking for and how to port/install it.

That's not entirely true. We have a broad spectrum of users, some of  
whom can be characterized as you are doing now, but some of whom cannot.

In fact, every 'advanced' user (defined here as people who do or have  
done unix system programming) I personally know uses some sort of  
port/package system to take care of the mundane details of things for  
them and/or to help manage the software they've installed.

I personally only started using macports on my machines because it  
made it much easier to uninstall software (so I could be sure to  
remove the old cruft when I upgraded - this was before macports  
handled upgrades).

> If you read through the questions people have had on the macports/ 
> darwinports mailing lists, however, you'll see that we've attracted  
> a somewhat different class of user, one which isn't even sure how  
> to add $prefix/bin to their path much less "make intelligent  
> choices about what should be installed and upgraded".

And by this logic, having worked in tech. support at an ISP, I can be  
sure that most people cannot ever successfully type their own  
username or password ;-)

> I'm not denigrating our users, I'm just saying that on the number  
> line between "grandma" and "Linus Torvalds", they're more towards  
> the left than the right side.  And that's not even a bad thing,  
> it's a sign of success that macports has managed to create  
> something with centrist appeal, but that also means you can't make  
> the assumptions about skill level that you're making.

We can make things 'just work' (for the most part) without linking  
things against inactive ports for end users (and I'm all for making  
things 'just work'). I'm just unsure that the path you're proposing  
is a good way of achieving the end goal of having things 'just work'.

>>> The fact that API/ABI compatibility is frequently broken is an  
>>> ugly little secret of our business and somebody, somewhere,  
>>> always ends up dealing with it.   For fan-out reasons alone, that  
>>> someone should be as far upstream as possible.
>>
>> Indeed, it should be handled upstream of macports.
>
> And, while we're wishing, let's also wish that upstream maintainers  
> also all made their software work perfectly on MacOSX without the  
> need for patches or special build procedures and that they all  
> agreed on a reasonable taxonomy and lived in peace and harmony  
> together, then macports (and all other ports systems) could just  
> retire themselves and end-users could deal directly with the  
> upstream providers.

In this case, I think there would still be a desire for some sort of  
packaging system.

> The fact is, however, that macports has established itself as "one  
> stop shopping" which means that this is as far upstream as users  
> should need to go, not to mention the fact that getting thousands  
> of software authors to change their ways seems markedly less  
> realistic than getting a few dozen macports maintainers to change  
> theirs.

... but it significantly increases the burden on port maintainers and  
raises the barrier to entry for people wanting to write portfiles.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20070310/34dab050/PGP.bin