GSoC idea for the binary issue (yet again)

[Jordan K. Hubbard]

On Mar 28, 2011, at 1:33 PM, Daniel J. Luke wrote:

> I don't think there are any good reasons any more not to just choose a package manager and go with it (be it rpm, dpkg, or whatever).

The only good reason I can think of is that both RPM and dpkg are semi-complex systems and will require anyone entering the problem space to fully understand them before they can be suitably bent to MacPorts' will.  I'm not saying that's an impossible challenge, certainly not, but it does constitute a barrier to entry that simply "starting small and working your way up" may avoid.  RPMs also have their own food chain, where SRPMs encapsulate the sources and building process and RPMs do the binary bit, and there may be some impedance-mismatch issues in having MacPorts take over some but not all of the work involved.   I also expect this to be the part where Jeff jumps up and explains how he's embedded a complete, stand-alone Common LISP development environment into RPM 3000 which allows you to do everything, up to and including implementing EMACS, inside the packaging system itself. ;-)

> ... back in the day, there were some thoughts that MP would integrate with the OS package manger (which would have been something new, apkg) and given that there was no chance of Apple using something GPL'd to install OS components - rpm and dpkg were rejected.

Actually, the GPL had no bearing in why those were "rejected" (and I think that's too strong a word considering that package creation shims were done for both).  I think the real reason was sadly more prosaic:  We didn't have any RPM / dpkg experts around who were really committed to making either of those systems work fully.

> I also think it makes sense to start with archives (simple tarred up destroots) and incrementally improve things (so we maybe end up with our own packages), since there hasn't been buy in for any of the various efforts to try to adopt one or another existing package manager.

I think that's a good idea for all the reasons I explained in my first paragraph.  You can start simple and just add things incrementally until archives are "smart enough" to do the job, with the pkg(1) tool providing the installation harness.  Of course, another route might be to grab the latest version of that Darwin port of *BSD's package tools and make those do the job too since archives are already slowly mutating into *BSD packages today and you could also just finish the job, but I have a hard time recommending those tools to anyone given that I wrote most of the code and know how horrible they are. ;-)

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110328/638950f3/attachment.html>