Okay, between your points, and those raised by other folks, I'm sold.
Someone from the IPS team should come up with a single slide or two with
these main bullet points. I suspect it might help for the folks like
me, who didn't see all of the big picture problems.
(For most of what I do, which is kernel software, SVR4 packaging works
fine.)
And, FWIW, I'd focus on the "intrinsic" problems of SVR4. "Lack of
Network Repo" or "Brittle Design" from other's points don't really
expose the real design limitations in SVR4 packages... the fact that it
doesn't work well for non-root install, or multiple concurrent installs
into different BASEDIRs is a pretty compelling argument, and the fact
that IPS is targetting much more than just OpenSolaris is also something
of which I was unaware.
-- Garrett
Christopher Kampmeier wrote:
>> On Wed 14 Nov 2007 at 02:02PM, Garrett D'Amore wrote:
>>> Please enlighten me. A couple of sentence exposition on what SVR4
>>> packaging gets wrong would be helpful. And, quite honestly, I think
>>> the IPS proponents need to have that explanation close at hand to
>>> satisfy the other people who are feeling the same way as I do.
>
> Limitations of SVR4 from an ISV's perspective:
>
> * lack of user-based install for applications
> * lack of multi-install for applications
> * lack of reusability on other OS platforms
> * many of the other limitations already stated
>
> (Many folks within Sun are playing the role of an ISV by virtue of
> their participation in open source and commercial software projects
> that deliver layered, multi-OS applications).
>
> Notes on the above:
>
> * Multi-install isn't just the ability to install two or more
> instances of the same named package. More importantly, it's the
> ability to install and manage multiple independent graphs of
> application packages on the same OS instance. Sure -R or --root with
> RPMs can be used to achieve a similar result, but those options
> weren't designed with the use case of managing separate application
> install images on the same OS. They were designed with the
> expectation that there's an OS as part of each "root".
>
> * User-based install: Apart from the developer use case, we often
> find that deployed application installations are managed by app admins
> that don't have the same degree of privileges of the OS level admins.
> There are fundamental issues with SVR4 in trying to grant appropriate
> privileges to app admins.
>
> * Reuse on other OS platforms: An attractive aspect of IPS is that we
> as an ISV will be able to package our apps once, reuse those packages
> across OS platforms and benefit from the repository-based capabilities
> across the board. Since much of our binary content is portable, this
> is a real benefit. I gather that porting SVR4 across a variety of OS
> platforms would be a daunting task given that multi-platform was not
> part of the original design criteria for SVR4. With IPS, we've
> already done it to a large extent by demonstrating IPS on Windows, Mac
> OS, Linux and Solaris.
>
> How many ISVs deliver their content exclusively via OS native package
> formats? Very few. For those ISVs and projects that don't or can't go
> native exclusively, the multi-platform aspect of IPS along with the
> overall IPS feature set is pretty compelling. Well, at least it is
> for us in our ISV role...
>
> Chris
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
