* Paul Armstrong <sunsolve at otoh.org> [2007-09-12 02:08]: > Do you have a copy of the prototype that we can play with (reading > about something and actually playing with it are two totally different > prospects)?
Pending approval, the intent is to move our Mercurial repository to opensolaris.org. You can then pull and install a copy from that; I'm asking the opensolaris.org team to give us some HTTP server space so that we could eventually run a repository. > You mention using ZFS. It's a good idea, but what do you think about > cross platform? Are we going to end up with yet another packaging > system that's completely incompatible with anything else and no one > else wants a part of (I can assume as far as the some communities are > concerned, because they didn't invent it). It'd be nice to move > towards some single thing rather than the mess we currently have > across environments (my current favorite is Debian, but it does have a > few quirks). I don't know if anyone else still uses SVR4 packaging > (HP? IBM?) but are they signed up to this as well? Maybe something > like an RFC, IEEE standard or addition to POSIX (yes, I know that's a > lot more work but it'd pay off handsomely for everyone)? I think these are good questions to explore. I have received some email suggesting that there is some interest in maintaining ports for other environments. Certainly the packaging system has to have a meaningful set of functionality on other filesystems than ZFS; how significant a reduction that set is is still open. > ZFS also gives a few limitations (at least in it's current > implementation). If I upgrade something trivial like tar, what do the > install and possible backout scenarios look like? I really don't want > to be rebooting to just upgrade tar and a zfs rollback means > unmounting which is effectively going to be a reboot if it involves > /usr. Whether a package transaction results in a clone or merely takes a precursor snapshot depends on the contents of the transaction. > One of the big issues in packaging is getting developers to sign on > and be consistent. A demonstration of this going well is Debian. The > bad flip side is RPM or companies like Oracle that just refuse to > participate in packaging at all (and damn the Oracle installer is > nasty). What ideas do you have that would get everyone doing something > that's sane without having to have a controlling board like Debian > does? That, I believe, is a distribution/adoption issue. Generally, packaging standards would be proposed as a best practice to ARC, and then enforced on new projects offering packages. Other distros (or package repositories) might be more lax in following such practices. > I see you're planning on making old and new style packages both > installable at the same time. Please make them both use the same > package tools so we don't have to run two different commands to get a > view of the system. Would you be thinking of improving the old style > packages with things like the ability to run an upgrade via a single > command so that they could better integrate with the rest of the new > style packaging? Having tried to make similar accommodations during smf(5) and ending up unhappy, I'm leery of making an early commitment to this kind of support, but I won't rule it out. > Converting the clusters into meta-packages would be another wonderful > middle step (especially if combined with the ability to upgrade old > style packages without doing the pkgrm/pkgadd dance). This is planned (if Danek hasn't already done it). > Patches, I agree, just kill them (or make them a collection of > pointers to entire packages). Packages with dependency trees are far > nicer. To really do away with dim sum patching, you're going to have > to split the packages down into fairly fine items (Debian style for > example) so that it's easy as a sysadmin to install just the minimum. > Of course, WANBoot and the like are going to have to support this (or > you're going to have to have a meta-package that supplies all the > drivers). SUNWCXall is an anachronism that needs to die. Agreed. We have actually two planned mechanisms for minimization: package refactoring and content filtering. It would be interesting to get some ideas about what content types people tend to remove, as well as hearing about brokenly-large packages in the current distribution. > Thinking about scripting, what I use it most for is: > * Dealing with multiple versions of Solaris. If I'm on 9 then > /etc/init.d scripts and /etc/rc3.d links, otherwise SMF manifests. > Remove the one that's not going to be used. > * Adding things the package depends on to run (such as users and > groups) and including some file modifications such as adding to > /etc/services or running crle to add a new library path specific to > this package. > * Seeding basic configuration. This can be done with configuration > management or by being able to tell the packaging system to install > the file, substitute some macros and then forget about it. The current plan is to offer actions (support of specific resources) for the middle case and to handle the basic configuration step via modifications to smf(5). Thanks for the questions! - Stephen -- sch at sun.com http://blogs.sun.com/sch/
