GSoC idea for the binary issue (yet again)

[Anders F Björklund]

Joshua Root wrote:

> On 2011-3-28 14:44 , Jordan K. Hubbard wrote:
>> 
>> On Mar 27, 2011, at 4:28 PM, Erik Österlund wrote:
>> 
>>> 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.
> 
> I'm pretty sure that by "ports tree" he means dports/. Avoiding that
> would be a win, as it does take a noticeable amount of time to initially
> download it with rsync. (People have filed bugs because they thought the
> installer had hung.)

When I wrote in the pkg(1) description and on the GSoC page that
it should work "without the ports tree", it wasn't because of the
bloat of needing to install a bunch of Portfiles and their files/.
(ports.tar.gz is currently at 14.2M, expanding to 89M something...)

The main reason was because Portfiles and the PortIndex describe
what *source* ports are available, but they don't describe the
*binary* packages. So what you would get is the "archives", where
port(1) is still used as the primary with binaries where available.

If the package metadata and its index is used instead, then you
could have the package manager read only that and not worry or
even know about how they were produced. Including not knowing Tcl,
not parsing Portfiles, not evaluate variants, not use images, etc.

Just seems to have a hard time finding such a package manager, with
rpm not being accepted and doing something like xpkg too much work ?
And that's just not about the package scripts, but all the rest too.
So use the archives and the +PORTFILE, skip the @pkgdep versioning...


If the server can be deployed to the point of building after every
commit or even on-demand, then the latest packages should be there.
(ignoring custom variants, of course. with those, you need to build)
But skip the binary-distribution-lagging-source-distribution part.

--anders