Danek Duvall wrote: > 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.
I agree that this should definitely happen before the project is finished, but not needed until the proof of concept validates the initial idea was not completely wrong. The problem of the suggested approach is that I don't want to invest the effort into refactoring packages and solving bugs in dependencies until there is working proof of concept, which is not easy to be put together without refactoring packages and solving bugs in dependencies :-) > 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 have filed bug for tracking this particular issue: 6479 SUNWipkg should be split to deliver pkg client and server separately > >> 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. Understood - thanks for clarifying this ! Jan _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
