Hi Brian, On Fri, 2007-05-04 at 00:19 -0400, Brian Gupta wrote: > I think the overall issue needs to be broken down into a number of > parallel initiatives/projects: > > 1) There is no common packaging system that meets the needs of the > community in use today. We need to come up with one that supports > dependencies, updates, and network repositories. (Mirrors are > welcome). All parts of Solaris will need to be repackaged with this > standard. SFW will be of supported of course, as will unsupported > packages. All packages will closely coordinate with Project managers > who are OpenSolaris members.
While this is an interesting topic, I think it's orthogonal to the question of open source software and repositories. > Also there is a question as to whether SYSV Package tools can be open > sourced. http://opensolaris.org/os/project/svr4_packaging/ > 2) There is no common repository for packages. This needs to be > addressed. There should be a common repository for OS packages, > including the kernel, as well SFW packages, and all the third party > and community maintained packages. (Supported or unsupported, this is > where people go to get Solaris packages). Sun needs to step up to the > plate for this one. I agree that a repository is needed for add-on packages, but I don't think it's a good idea for what's _in_ Solaris. What goes into Solaris gets tested as an integrated product. There's no guarantee that arbitrary combinations of packages will work. In fact consolidations often need to synchronize deliveries to ensure that things don't break. More fine grained packaging and better dependency information can help with this. > 3) If Sun seriously expects third party GNU maintainers to build > Solaris packages, they need to provide the build environments, or it > just won't happen. Again, Sun really needs to step up. I don't think it's realistic, or even desirable for GNU maintainers to build Solaris packages. I responded to this separately. > 4) We need to figure out how SFW packages are going to be maintained. > I have heard to conflicting visions, both from within Sun. One vision > says, stick to a specific version of an Open Source tool, and then > just back patch that selfsame version until the next named release of > Solaris. The other vision says that if the mainline opensource app has > a few verion increments and they warrant updating the SFW package, go > ahead and grab the new version and recompile it. We really need to > wrap our hands around this, as there is a serious mental divide here. > (I actually lean towards a mixed method myself). (This should be > hashed out in its own thread, and then a formal should be proposed to > the powers that be.) This is really dictated by the interface stability picked for each component. Backporting changes should be avoided as much as possible because: - it requires a lot more resources than what we have - potentially introduces new, Solaris specific breakages - makes Solaris that weird OS where libfoo was forked and is neither version n nor n+1... So, I think the rules are quite clear: 1) if there is no incompatible interface change then use the new version 2) if there is an incompatible interface change then the interface stability defines what can be done. The choices are: a) go with the community and break the interface b) don't update (bad) c) backport the important changes So it's all about choosing appropriate stability labels for each component. > 6) This is really part of one, but it controversial and will need top > level buy in. Whether or not package x is supported or unsupported, it > should be installed in the same place. e.g - /usr/bin/x I agree with this and the SFE (spec-files-extra) packages install to /usr, as will the pkgbase packages. > Ideally once this is all in place, one could run "spm-get upgrade-all" > and after some time, the system would be running the latest version of > OpenSolaris. except opensolaris is not an OS (; Laca
