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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
