Bill Guindon
10/7/2004 2:47:00 AM
On Thu, 7 Oct 2004 10:46:24 +0900, Peña, Botp <botp@delmonte-phil.com> wrote:
> Gavin Sinclair [mailto:gsinclair@soyabean.com.au] wrote:
>
> > I'm getting lost again. What is it that Windows users care
> > or not care about? :)
>
> w regards to packaging/deployment? Nothing. Only admins care on deployment.
Actually, I'd imagine that varies by user (being one myself). If any
of you know what it is that I care about, please, drop me a note (I
sometimes forget).
> and pls, for package makers, make gui-packagers a last priority.
Couldn't agree more. I'd also add that both work on Win32, both are
written in Ruby, and adding a GUI to either would (I assume) be about
the same amount of work. In fact, I'd love to see a generic GUI that
could work with both of them, and I'd even be willing to put some
effort towards that goal.
> Packagers are like installers, and, as such, must be:
>
> 1. robust
> 2. able to provide rollbacks
> 3. lean/light
> 4. capable for remote/central deployment
> 5. must run in almost all platforms (and platforms of diff vers)
> 6. capable of being hook in nms like openiew/sms/tivoli...
>
> #3 to #6 are main reasons I do not like gui packagers :-(
I'm also not so sure that I want a packager as part of the main
install, or maybe not just yet. It seems that both are going through
a growth phase, and neither of them should be considered the de facto
standard atm.
They support roughly the same number of packages, but do it from
different perspectives. They also serve different needs, availability
vs. stability. On both of these fronts, it seems RPA has the lead
right now, but Gems could quickly take over on the availibility front
(and I imagine it will at some point).
I'm open to the idea of a packager coming with the standard install,
but I'd like to hold off until Gems and RPA have gotten a bit more
stabilized. As it's been pointed out earlier, adding either one to
the base install now, can have a serious impact on short term
development, and I'd like them both to have some breathing room for a
while.
If nothing else, I'd like to wait until they can do an independent
installs of each other (or at least the included one can) --
independent in the sense of, remove the original, and the replacement
still works fine.
For now, my answer would be... if you can install Ruby, you can
install the packager of your choice. That one additional burden is
not a huge one, so let's not stunt the growth of either of them for
the sake of including one "as soon as possible".
--
Bill Guindon (aka aGorilla)