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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
