Archives and Packages (was Re: Universal and binary builds)

[Jordan K. Hubbard]

On Mar 28, 2009, at 12:16 PM, Jeff Johnson wrote:

>
> On Mar 28, 2009, at 2:59 PM, Jordan K. Hubbard wrote:
>>>
>>
>> I don't know if "popular" would be the word I would use.  Neither  
>> solution has ever actually been *completed* would be a more  
>> accurate statement, so the resulting popularity of said solution is  
>> impossible to gauge.  The MacPorts project has always had a rather  
>> lackluster attitude when it comes to the challenge of packaging up  
>> and delivering software to end-users, but the fact remains that  
>> most end-users just want to say "I want this, that and that other  
>> thing over there - make it happen please!" with the minimum amount  
>> of downloading/build time.   If you look at FreeBSD ports, for  
>> example, where it could easily be said that a "sophisticated  
>> audience" is the target (FreeBSD's historical attempt to grab Linux  
>> mind/marketshare notwithstanding), most users actually install  
>> software by typing "pkg_add -r gimp" and letting the package  
>> management system do the rest, they don't think of "cd /usr/ports/ 
>> graphics/gimp; make all; make install" as the most convenient/ 
>> desirable way of doing it, and why should they - the latter  
>> approach takes at least 10X the time to complete.
>
> Um, what is your definition of "completed"?

My definition of "completed" from the perspective of "Packages  
delivered by the MacPorts project using some hardware that Apple  
donated for the purpose" would be:

1. Every time a port changes or is added to the collection, some  
package-creation machinery behind the scenes fires up and creates a  
reasonably universal package with, at a minimum, the default variants  
selected.

2. Each package is the full, bit-for-bit equivalent to "port install",  
assuming all the same defaults are used, for any given port.  This  
includes any and all run-time actions, of course, such as creating the  
role user account for some database server.

3. The end-product of item #1 is available on The Intarweb somewhere,  
for easy direct downloading and access through the software in item #4.

4. We provide both a command-line "pkg_add -r equivalent" and a Cocoa  
front-end which allow end-users to quickly and easily ask for a  
package install/upgrade, any and all dependencies for said package  
also being transparently dealt with behind the scenes.

5. [Purely Optional "Nice to have"]  Also support the notion of  
requests, in the toolset for item #4, for specific variants of  
packages, causing said packages to be built on-demand on the "package  
server" and added to the cache.  A heavy-weight prospect to start  
with, for sure, but one which would also taper off as all of the most  
popular package/variant combos were created and added to the package  
cache.  That would make the whole thing look even more like "f**king  
magic" to the user.. ;-)

Again, I'm only suggesting that "steps 1-4" are mandatory here.  You,  
as an RPM guy, might also be tempted to say "RPM has that already!"  
which, of course, would be both accurate and completely wrong since  
this isn't about "a package format", this is about choosing a package  
format (either existing or roll-our-own) and then doing the other 90%  
of the work, which is entirely on the "service provision side."  The  
gist of my original message could even be re-stated as:  "I'm not  
interested in the 10%.  That's comparatively trivial.  Let's talk  
about the remaining 90%, because that's what's required if there's  
ever any hope of delivering a ``professional service'' to end-users."

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090328/06c60436/attachment-0001.html>