I'm interested in the answers to Peters questions and agree that the response (or lack thereof) is a little surprising but they may just be taking time to think about it like I did.
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)? 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)? 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. 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? 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? 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). 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. 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. There's also the private email I sent to you guys after the Bay Area picnic. Paul This message posted from opensolaris.org
