Universal and binary builds

[Jordan K. Hubbard]

Oh gee.  Package management.  My favorite subject....   TEN YEARS  
AGO. ;-)  </needless-sarcasm>

On Mar 23, 2009, at 8:53 PM, Bradley Giesbrecht wrote:

> Are uninstall options within a pkg difficult?

Yes.  The .pkg format is basically just cpio on a small dose of  
steroids.  Strictly one-way, and the pre/post-flight scripts are also  
allowed to do pretty much anything else they want, assuming you hand  
them the privileges to do so (which, of course, almost everyone does).

> Many installer distributed in dmg's provide an uninstall script.

That is an entirely optional "hi, we're being nice" extra that the  
vendors who produce those dmgs roll by hand, generally speaking, and  
they don't exactly scale to hundreds of installed software packages.

> I guess I just don't see the appeal of rpm. What do you see as the  
> advantages of rpm?
> Would rpm be internal to the macports port command and leverage rpm  
> dependency checking or something?

I think you're asking the wrong question.  The right question is not  
"is package format foo better than package format bar?" but rather  
"what exactly are we trying to do?"   I think the MacPorts project has  
essentially paralyzed itself with respect to package formats, and the  
subsequent task of package production, by taking the position of  
"we'll just support all package formats!  badly!", thus essentially  
rendering all choices equally mediocre and unappetizing to anyone  
wishing to experiment with this side of MacPorts.  That's a shame,  
because I think it's a good example of some bit of code filling a much- 
needed vacuum, tricking future generations into walking down the wrong  
path and into a bad part of town. :-)   "What's ``the right path''  
then?", I hear you ask.  Glad you asked!   The right idea is to go  
back to that more fundamental "what exactly are we trying to do?"  
question and try to answer it first, deciding what constitutes a  
package in MacPorts-land and how much of a role, if any, the MacPorts  
project wants to take in producing packages for popular consumption.   
Once you have those answers, assuming that you've decided to go  
anywhere with packaging at all, you can attack the problem by writing  
something strictly to spec, swearing under pain of death that it will  
absolutely never be any more complicated or feature-full than it needs  
to be at any given time.   That will keep you out of the La Brea  
Tarpit of package management tools, where the temptation to be too  
clever/forward-looking can quickly lead to an explosion of options and  
special-case behavior that rapidly complicates what should actually be  
relatively simple.

> I'm thinking of all the software I have downloaded in the past like  
> php, mysql, gimp, foo2zjs, foomatic-rip, gutenprint etc... that are  
> already distributed via dmg's.

I'll also bet that the majority of those dmgs also bundle each and  
every dependency they need, thus ensuring that if php, mysql or gimp  
from your list above need, say, libjpeg, they all have their own copy  
so that you can drag the resulting bundle around.  That's always one  
way of doing it, of course, and even one with certain advantages (or  
drag installs would not be as popular as they are), but it's even less  
of a managed-package scenario than what most users currently have in / 
opt/local.  Some might even choose to continue to build everything  
themselves (thus raising the overall carbon footprint of Mac users  
everywhere ;-) rather than go "the dmg route" because they like the  
notion of non-duplicated bits and targeted / small security updates.   
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.

Just my two cents. ;)

- Jordan