Archives and Packages (was Re: Universal and binary builds)

[Jordan K. Hubbard]

On Mar 28, 2009, at 12:55 PM, Jeff Johnson wrote:

>> My definition of "completed" from the perspective of "Packages  
>> delivered by the MacPorts project using some hardware that Apple  
>> donated for the purpose" would be:
>>
>
> I see. So the 2700+ packages I built from darwinports on several  
> occaisions don't
> qualify because I bought my own hardware. My mistake ...

No, they don't qualify simply because of item #1 on my list.  "If it's  
not automated, and therefore always up-to-date, it does not exist"  
would be a fine rule of thumb where this is concerned.  We need a  
sausage factory, in other words, not just individual craftsmen who can  
lovingly create each and every sausage by hand.  You created a whole  
bunch of packages, sure.  Did you create an infrastructure for  
creating packages and check the code into the MacPorts tree, where  
others could collaborate with you?  No.  Sorry, but who's hardware you  
used is the least relevant point above.


>> 1. Every time a port changes or is added to the collection, some  
>> package-creation machinery behind the scenes fires up and creates a  
>> reasonably universal package with, at a minimum, the default  
>> variants selected.
>>
>
> Ypou are talking about build infrastructure, not packaging per-se.
> That's a different type of "incomplete".

I think I made that point at least 3 times in my message, so what are  
you trying to tell me here?  That you and I are finally on the same  
page?  Gosh, I sure hope so. :-)

>> 2. Each package is the full, bit-for-bit equivalent to "port  
>> install", assuming all the same defaults are used, for any given  
>> port.  This includes any and all run-time actions, of course, such  
>> as creating the role user account for some database server.
>>
>
> Can port verify its installs or is "bit-for-bit" defacto?

"bit for bit" is the validation test.  Once we've verified that for a  
reasonable cross-section of ports, I'd say we can declare victory on  
the build tools and focus on some other part of the infrastructure.

>
>> 3. The end-product of item #1 is available on The Intarweb  
>> somewhere, for easy direct downloading and access through the  
>> software in item #4.
>>
>
> Distribution on the intraweb is a different form of "incomplete"  
> unrelated to packaging per-se.

Methinks that someone is either being deliberately obtuse or is  
constitutionally incapable of seeing the bigger picture. ;)

> Again, depsolving != packaging.

See above.

> Build-on-demand is hardly a "Clicky-clicky" end-luser browsable  
> interface,
> and is quite at odds with your (otherwise reasonable) KISS is always  
> better.

Again, I said this was an extra-credit sort of item, which is why I  
took pains to separate it from items 1-4.

> Ask and ye shall be granted. Otherwise I'm just a tourist with  
> camera in the land of MacPorts,
> with a revokable visa ...

So, in order to "grant my wish", you're saying that you have also  
accepted the Religion Of The Four Criteria into your heart and will  
next start contributing some MacPorts code to accomplish this?   
Huzzah!  I can hardly wait! :-)

- Jordan

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