On Fri, Feb 06, 2009 at 12:14:05PM +0100, jan damborsky wrote:
> For instance, let's assume I want to create my own tiny Solaris
> distribution (e.g. to be deployed on some kind of embedded system) using
> Distro Constructor. In this case, I want to have complete control over
> what is to pulled into my proto area and present in final image by
> explicitly specifying all packages I am interested in.
>
> e.g. why should I be enforced to install SUNWpython-cherrypy SUNWipkg
> depends on, if I know I will be using pkg only as a client ?
If you're building your own distribution (and thus taking your customer
service into your own hands), then you have license to break packages apart
and recombine them as you see fit, which is what you should do here. The
ground rules are that after a package is installed, all the bits necessary
for it to run have also been installed. If the package boundaries are too
coarse, then that's potentially a bug in the package (as it likely is in
this case; we've been discussing pulling SUNWipkg into two pieces).
> I can think about another scenario. Let's assume that package A depends
> on functionality delivered by package B. I decide that instead of
> delivering that functionality by installing B from IPS repo, I will
> rather compile latest version from sources (e.g. because it contains some
> additional feature I would like to take advantage of). How this scenario
> fits in broader IPS packaging philosophy ?
You could
a) install A, dragging in B, and overwrite B;
b) install A, dragging in B, install B' in an alternate location and
point A at it; or
c) publish B' into your own depot and install A, dragging in B'.
There'll likely be bumps here, particularly with c), but we haven't exactly
been concentrating on how to deliver an untested system to the customer.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
