On 5/7/07, Steven Stallion <sstallion at gmail.com> wrote: > You can view it here: http://docs.google.com/View?docid=dhbvzvv7_0f9prct > > Please comment - there is a lot to talk about :)
Most of my comments come around supportability by a third-party support organization. * Pre-built vs. locally customized Is there a special fmri or other indicator with a package to indicate that it is not the "official" build? If I inherit a system from the old admin and need to update custom built packages, is the knowledge of the recipes and pkgbuild command available in the package database? * Stable vs. long-term usable The goal to provide an easy upgrade path to the latest bits is an admirable goal. The attempt to eliminate package duplication that is common today is also quite desirable. However, I worry that this will lead to a lack of binary compatibility that we all know and love. Perhaps a hybrid approach is best. A particular "stable" release has packages installed in one location that are kinda like the bits in /usr are today: typically well-aged before GA and outdated before you know it. For those that require long-term ABI stability, this is the the thing to build and test against. Critical fixes can and should be backported. Anything that can't pass ABI compatibility (or requires something that strays from "stable" ABI compatility) installs in an "unstable" location. The FMRI and package name namespace should be rich enough to support having one stable and one unstable version of the package installed. Presumably the unstable packages would be linked such that they prefer libraries in the unstable tree but can also use items from the stable tree. Build recipes may tweak this if a particular binary is known not to work properly with the items in the stable tree. What does this buy? - Most *Solaris support organizations will likely support the stable tree. - ISV's have a third-party supported ABI guarantee to test and build against. - More adventurous organizations (end-users, ISV's, etc.) can bring in as much unstable as needed to support their needs. Special support organizations (e.g. OpenSolaris community, niche support providers, etc.) may choose to offer support for the unstable branch. * Outstanding issues Some notion of package clusters, both pre-defined and end-user-defined are important. Removal of a package cluster should probably remove the dependencies that are not required by some other specifically requested package or cluster. Being able to point at repositories of recipes for building packages would be very helpful. I'm thinking of pointing at a mercurial or similar repository, but it could be in a different distributed authoring and versioning format. Package metadata that points to OpenSolaris or other community maintained wiki pages (version-specific) would be quite nice. If Sun wants to point their packages to docs.sun.com which becomes a reformatting of community developed wiki pages, that is fine. There are times when you really care about the version of the package that is installed. Consider Apache as an example - version 2.0 gained acceptance rather slowly making the ability to choose 1.3.x and/or 2.0.x quite important. -- Mike Gerdts http://mgerdts.blogspot.com/
