Francois Saint-Jacques wrote: > On Sat, Jun 23, 2007 at 10:42:26AM +1200, Glynn Foster wrote: >> Packaging > > Many individuals, including me, are interested in the packaging system for > Indiana. I believe that it is important to attack the problem of packages > management at the moment. We cannot conceive an operating system without > having a process for propagating and upgrading packages. I would really > like to see a packager community where we could work together to > effectively integrate software in OpenSolaris with high quality standards > (SMF daemon aware, FSH compatible). Moreover, we could then work on the > desktop part and/or other software integration. Some proposals: >
What you suggest above sounds more like "porting of software" such as the Companion project, while the items below are perfectly covered by the existing Installation and Packaging Community. > 1. First of all, it would be necessary to create a standard library for > packages 'libpkg', not to confuse with the current libpkg, with generic > functions such as 'package_add(), package_check(), etc'. There was a > post on the forum install-discuss but I am not able to find it > (Dave do you remember which post?). This would allow use to combine > multiple tools (pkg*, pkg-get) with one clean implementation. > > 2. Re-code pkg* binaries to use libpkg. In order to accomodate linux > users, I had already suggested this in the Indiana-discuss list: create a > new tool 'pkg add|delete|info'. One tool to rule them all that would also > use libpkg. > I am unsure which post you may be referring to above. > 3. The holy grail: 'pkg-get' that support multiple repositories, live > network upgrade, multiple sources (ftp,http,https,filesystem). On this > subject, I propose having an official core repository that ONLY contains > ON integration (base system). > Why would a repository restricted only to ON be attractive? Consolidation boundaries can be somewhat arbitrarily drawn and do change over time, and I think is fairly orthogonal to the functionality provided by a package, which appears to be the primary point of interest. Heck, as things stand right now, such an ON-only repository wouldn't even include the current packaging tools, which seems wholly undesirable for what you're suggesting. Dave
