GSoC idea for the binary issue (yet again)

Daniel J. Luke dluke at geeklair.net
Mon Mar 28 19:56:42 PDT 2011


On Mar 28, 2011, at 9:06 PM, Jordan K. Hubbard wrote:
> 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.  

That's true, although I think there would be a good case to buy into whatever packaging system was selected (and therefore more have MacPorts bend to the will of the packaging system than anything else). This would possibly involve getting rid of the registry entirely (or other things that people might be reluctant to do).

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

Maybe not at first (when MacPorts was still trying to be 'package system agnostic' and support multiple package systems simultaneously), but it was certainly a factor around the time integration with the almost mythical apkg was being discussed.

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

From my perspective, it mostly felt like it was more a matter of no one being willing to put a stake in the ground and just go for one system, because they all had issues:

- .pkg has some well known deficiencies
- apkg never seemed to actually exist
- rpm/dpkg weren't ever going to be used by Apple

At the time there was still a good amount of effort being spent on using things provided with the OS as dependencies, and so there were various strategies discussed for integrating with whatever Apple was using to install software (either reading .pkg receipts and using that to identify installed packages, using some mythical apkg functionality to do the same, or somehow bridging whatever Apple was using with whatever system MacPorts was using).

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

I think we agree 100% on this.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+





More information about the macports-dev mailing list