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

[Jeff Johnson]

On Mar 28, 2009, at 3:44 PM, Jordan K. Hubbard wrote:

>
> On Mar 28, 2009, at 12:16 PM, Jeff Johnson wrote:
>
>>
>> On Mar 28, 2009, at 2:59 PM, Jordan K. Hubbard wrote:
>>>>
>>>
>>> I don't know if "popular" would be the word I would use.  Neither  
>>> solution has ever actually been *completed* would be a more  
>>> accurate statement, so the resulting popularity of said solution  
>>> is impossible to gauge.  The MacPorts project has always had a  
>>> rather lackluster attitude when it comes to the challenge of  
>>> packaging up and delivering software to end-users, but the fact  
>>> remains that most end-users just want to say "I want this, that  
>>> and that other thing over there - make it happen please!" with the  
>>> minimum amount of downloading/build time.   If you look at FreeBSD  
>>> ports, for example, where it could easily be said that a  
>>> "sophisticated audience" is the target (FreeBSD's historical  
>>> attempt to grab Linux mind/marketshare notwithstanding), most  
>>> users actually install software by typing "pkg_add -r gimp" and  
>>> letting the package management system do the rest, they don't  
>>> think of "cd /usr/ports/graphics/gimp; make all; make install" as  
>>> the most convenient/desirable way of doing it, and why should they  
>>> - the latter approach takes at least 10X the time to complete.
>>
>> Um, what is your definition of "completed"?
>
> 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 ...

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

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

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

> 4. We provide both a command-line "pkg_add -r equivalent" and a  
> Cocoa front-end which allow end-users to quickly and easily ask for  
> a package install/upgrade, any and all dependencies for said package  
> also being transparently dealt with behind the scenes.
>

Again, depsolving != packaging. FWIW, both yum & smart dealt then (and  
likely deal now)
with both the issue of depsolving, and with a GUI. Alas not Cocoa,  
which is most definitely
a superior GUI. But lack of a GUI is a different form of  
"incomplete" ...

> 5. [Purely Optional "Nice to have"]  Also support the notion of  
> requests, in the toolset for item #4, for specific variants of  
> packages, causing said packages to be built on-demand on the  
> "package server" and added to the cache.  A heavy-weight prospect to  
> start with, for sure, but one which would also taper off as all of  
> the most popular package/variant combos were created and added to  
> the package cache.  That would make the whole thing look even more  
> like "f**king magic" to the user.. ;-)
>

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'm only suggesting that "steps 1-4" are mandatory here.   
> You, as an RPM guy, might also be tempted to say "RPM has that  
> already!" which, of course, would be both accurate and completely  
> wrong since this isn't about "a package format", this is about  
> choosing a package format (either existing or roll-our-own) and then  
> doing the other 90% of the work, which is entirely on the "service  
> provision side."  The gist of my original message could even be re- 
> stated as:  "I'm not interested in the 10%.  That's comparatively  
> trivial.  Let's talk about the remaining 90%, because that's what's  
> required if there's ever any hope of delivering a ``professional  
> service'' to end-users."
>

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

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