GSoC idea for the binary issue (yet again)

[Erik Österlund]

Mar 28, 2011 kl. 5:44 AM skrev Jordan K. Hubbard:

> 
> On Mar 27, 2011, at 4:28 PM, Erik Österlund wrote:
> 
>> The goal
>> Being able to download and install binary "packages".
> 
> Sounds great!  Are there multiple GSoC applicants working on this simultaneously, or just one of you, or ... ?

I don't know. I've been interested in this for quite some time and wanted to do this GSoC project. However it seems I am not alone. Hope this potential issue can be resolved somehow.

> 
>> Binaries‚ what are they
>> In my proposal, the idea is to use binary archives instead of "real" packages to keep it simple, doable, and make it happen. So each port will be compiled and archived by MPAB, and the result is used.
> 
> Well, if you have binary archives which are also able to contain the original Portfile *and* have a pkg tool which knows how to run the relevant procedures out of that Portfile, then I hate to tell you this but you now have "real" packages in every meaningful sense of the word. :-)  It's not the same package system as used by *BSD or Red Hat or Debian or even Mac OS X, but it's still a real package system and should be proud of this fact rather than ashamed!  ;)
> 

Great!

>> Issue 1
>> The first issue is that a command for installing binaries without requiring Xcode or the ports tree is wanted, so that users can easily install binaries without needing a whole bunch of dependencies. The suggestion is to create a new command, which is what I want to do during the summer. This command, let's call it pkg, will install binaries only, without the need for the whole ports environment (ports tree and Xcode, but still registry and TCL).
>> 
>> Note here that a TCL interpreter is still needed because of the scripts in the Portfiles! There are as I see it 3 options. 
> 
> There are a lot of things you seem to be doing to avoid installing a copy of Ports, when I actually have to wonder why this is so important.  The entire "ports tree", if you don't actually include the build recipes in dports, is less than 10MB.  You could simply depend on this being in a port-1.0 package which could be installed as a dependency if the user does not already have MacPorts installed on their system.  Once you can assume that /opt/local contains the MacPorts distribution before your first post-install / post-activate rule will ever run, it makes things a lot simpler IMHO.

Yes I guess that is fully possible. My thinking was just that it shouldn't be necessary as shipping Portfiles with the archives seemed like a much better idea. And as you said before, we're not really interested in the "best solution", only "a solution", so that we actually get some results.

> 
>> I would implement a pkg(1) command in Objective-C using MacPorts.framework to interact with the registry.
>> The command would fetch archives and their belonging Portfile, unarchive it at destroot and run the scripts in the Portfile using a TCL interpreter (but still without need for the ports tree or Xcode).
> 
> I think that's a perfectly reasonable thing to do, especially as it will ensure that MacPorts.framework is exporting all of the "right API"  in terms of how you can drive it to build packages on demand or register things in the registry on behalf of the pkg command.  Stop me if I'm incorrect, but the registry is also only ever modified as part of installing software in MacPorts, right?  This suggests that the only thing that will ever write into the registry is the pkg command, all other parts of the system simply using the registry read APIs.

Yes that is right, if we see pkg(1) as the installation tool. I mean if we compile from source, it would also modify the registry when it installs, right? But that's like the same thing as building an archive and installing it with pkg(1).

> 
>> If time allows, I would like to look at the build-aspect of the system too with MPAB, but it feels like a different project, does it not?
> 
> Well, if your system is designed to ever allow on-demand package building, it also suggests that the server side needs to know how to get MacPorts to build things on its behalf, but that doesn't necessarily imply MPAB and a mass-building scenario either.

Right. Seems reasonable, and I'll make sure that works as well I guess. The summer is long!

- Fisk

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