> On Sat, Jul 21, 2007 at 09:51:13AM +0100, a b wrote: > > > On packaging systems / formats that already support > hierarchichal bundling > > of software, there is a notion of a > > > > depot > > bundle > > product > > subproduct > > fileset > > It seems awfully complicated to give each level of > the heirarchy a > different name, and somewhat arbitrary to fix the > heirarchy at five levels > (though I guess only three are required). Have those > choices proven really > natural in practice?
Yes, depending on how complex the bundle is. Sometimes, all that's needed is a bundle with two products. Sometimes, I'll go all the way down to the subproducts. Consider for example a product that I've packaged: [user at host][~/devel]> /usr/sbin/swlist -l product -l subproduct -l fileset -s /var/spool/sw/ABCDbind-9.3.2-P1,REV=2006.10.07.01-HP-UX-B.11.00-hppa1.1.depot # Initializing... # Contacting target "aldea"... # # Target: aldea:/var/spool/sw/ABCDbind-9.3.2-P1,REV=2006.10.07.01-HP-UX-B.11.00-hppa1.1.depot # # BIND 9.3.2-P1_REV=2006.09.27.01 BIND # BIND.Development BIND development files BIND.Development.BIND-PRG 9.3.2-P1_REV=2006.10.03.01 BIND development files # BIND.Manuals BIND manual pages BIND.Manuals.BIND-ENG-A-MAN 9.3.2-P1_REV=2006.09.27.01 BIND man pages # BIND.Runtime BIND Runtime BIND.Runtime.BIND-SERVER 9.3.2-P1_REV=2006.10.03.01 named and related binaries BIND.Runtime.BIND-SHLIBS 9.3.2-P1_REV=2006.10.03.01 BIND shared object libraries BIND.Runtime.BIND-STARTUP 9.3.2-P1_REV=2006.10.03.01 Startup/shutdown scripts BIND.Runtime.BIND-UTILS 9.3.2-P1_REV=2006.10.03.01 named client binaries [user at host][~/devel]> As you can see, the granularity allows for a nice logical split of components; and I could also bundle any other products that BIND product might have needed into a bundle... In principle though, I agree with you: one could get away with just bundles and products, if need be. It's just that on HP-UX, it wouldn't be natural. > It also seems strange that that > "[c]ustomer creation > of bundles is not supported". Why would that not be > a useful operation for > a customer or ISV? Honestly, I've no idea. It seems to work just fine. I don't necessarily understand why a 3rd party would even need support from hp for their own software bundles. Those wouldn't be a piece of hp's software anyway. > We'll have the concept of the depot (in fact, our > server is currently called > pkg.depotd, though we've been calling the depot the > repository, a la > conary), and the fileset (package), but filesets will > be hierarchical. So it will be a hybrid between HP-UX's depots and IRIX's dists? I was thinking that it might make sense if we contacted sgi to see if they're willing to open source their own software subsystem, considering that IRIX is discontinued and that `inst` supports System V packages. `inst` has almost everything that Stephen Hahn listed as requirements, plus a lot more. Additionally the System V compatibility is surely a big plus. Any concensus on that? This message posted from opensolaris.org
