GSoC idea for the binary issue (yet again)

[Anders F Björklund]

Jordan K. Hubbard 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.  

Both "rpm" and "srpm" was added to MacPorts as an alternative to pkg and portpkg, but both the .rpm and the .pkg have the shortcoming that the scripts are not exported and that they don't interact with the registry and the other ports (those not installed from packages).

The mapping is a straight-forward one-to-one, so the rpmbuild .spec just calls port(1). The Portfile and files.zip are both included in the .src.rpm. For the binary .rpm construction, it reuses the regular destroot. So there the %prep/%build/%install/%clean are empty.

But using RPM for Ports will never happen...

And if you like dpkg, there's Fink already ?

> 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. ;-)

It does embed Tcl, if needed (by MacPorts).

>> ... 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.

If it matters now, RPM changed to using LGPL.

>> 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.

A small beginning would be to *enable* "portarchivemode" for port, so that it would actually use archives to start with. Then when MPAB is deployed, port -b and "archivefetch" is "a start". And have Google sponsor the custom pkg(1) package manager development this summer.

> 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. ;-)

You could use RPM directly on Darwin, too...

Like with http://rpm4darwin.sourceforge.net/

--anders