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

[Jordan K. Hubbard]

On Mar 28, 2009, at 5:21 AM, Anders F Björklund wrote:

> Jordan K. Hubbard wrote:
>
>> It would be nice[er] IMO if a solution could be devised which makes  
>> "port install foo" and "pkg install file:///foo.xar" lead to  
>> exactly the same place.  Well, to be even more precise, it would be  
>> nicer still if "port install foo" simply became a wrapper around  
>> "port package foo -o /var/tmp/<somewhere>/foo.pkg && pkg install file:///var/tmp 
>> /<somewhere>/foo.pkg && rm -f /var/tmp/<somewhere>/foo.pkg" so that  
>> the base MacPorts infrastructure could just get out of the business  
>> of directly installing bits on the system.
>
> This would still require someone to choose/write the "pkg" program,
> and then make all invocations of "install" go through this layer...

Yep!  That's the basic idea.

> And both using the RPM package manager and writing a new one was tried
> (with "dp_light" and "xpkg"), neither solution has been very popular ?

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.

> The simplistic alternative here was to continue with the old archives,
> and just enable "archivemode" to create them before any installation.

Too simplistic, I think.  Again, installing a package is not simply  
"de-archival" or we'd have taken that approach a long time ago.  Just  
grep through the current macports collection for all the ports with  
pre/post install rules, for example.  What happens with those?  What  
you're proposing would essentially require an end-user to have the  
entire macports collection still on their hard drive so that they  
could simply skip the "build step" and de-archive instead, but still  
rely on the Portfiles for all the other install-time information/ 
procedures.  I suppose that's an incremental improvement, but I still  
don't think it's what users want in the final analysis.

What users *really* want is a graphical front end that talks to a  
server somewhere "in the cloud" and pulls down an index of available  
packages for their platform (which pkg_add -r also does behind the  
scenes - if you're on Intel running FreeBSD-7, it grabs packages just  
for that, vs what happens if you're running FreeBSD-current on, say, a  
SPARC platform) then, because we're catering to Mac users and not  
FreeBSD users, allows the user to just click on the things they want,  
automatically pulling down dependencies and running the post-install  
actions as necessary.

> This is similar to the "package format" that Slackware Linux uses.
> Has a couple of shortcomings, but at least it is simple enough...

Slackware's package manager also provides for install-time actions and  
tracks dependencies.  There's more going on there than meets the eye. :)

- Jordan