Peter Tribble wrote: > The advantage things like eclipse have is that they're simply > distributed as archives - which is what people want. Unzip > and go. As a developer, I simply don't want to mess with anything > more complex, and I certainly don't want to have to learn different > tricks on different platforms.
But tarballs don't solve the continuing update problem. Eclipse (and NetBeans) solve it by having that initial tarball you unpack contain a complete update manager scheme. This *really* doesn't scale: it ends up making you have to learn different tricks for every application, not just every platform. > > As it is, I simply won't touch applications like openoffice that > force packages down my throat. > >> ** Application Administrator >> >> In large data centers, the responsiblity of administering application >> "stacks" may be divided from the responsiblity of administering the >> underlying system. This means that the administrators who install, >> upgrade, and migrate the applications don't have full root access. >> While it's true that there are a few operations needed for complete >> deployment of a server, like adding and enabling an SMF service (or >> manipulating /etc/init.d and /etc/rc?.d for older Solaris >> releases), those operations aren't always needed, and when they are >> they are generally easily accomplished under typical data center >> change control procedures. Getting an authorized user to run a few >> specified commands at a specific scheduled time is much more likely >> than getting an authorized user to run through an often lengthy and >> somewhat trial-and-error procedure like the Java ES component >> installations. > > Why stop halfway? Have the root user explicitly create a new software > domain, and delegate it to the application administrator. I'm not sure how a "new software domain" helps here. Delegating a new software domain can't delegate the ability to start random code as root (that's just the same as giving people root access in the first place) so there still needs to be some other interaction point to "go live". Given that, what is a "new software domain" other than a file system the delegatee can write into? Sysadmins can already create and control those. > Is it > possible to create an SMF delegated restarter for that user, as > well, so the service creation/start/stop/management are handled > as well? This sounds like more than the restarter, since the ability to install SMF manifests also needs to be delegated. One would need per-user SMF config databases, by the time you do that you might as well create a zone. (I don't see what use case this satisfies that zones don't.) >> ** Why not just use tarballs? >> >> As mentioned above, the way application developers deal with our >> use cases now is to create tarballs (or functional equivalents like >> cpio archives.) This clearly works, at least for initial software >> installation. > > So it's clearly a good answer for the developer use case. > >> Where it is lacking is in the inventory management >> and dependency checking provided by a packaging system. > > I don't see this as an issue for the developer case. Then why have both Eclipse and NetBeans gone to the trouble of creating them? Clearly other people see it as an issue. > >> * What are the risks? >> >> ** Not "everything" in the system is visible to the SA >> >> Up to now, everything installed on a particular operating system >> instance through the packaging system has been registered in the >> same place. > > Well, no. pkgadd -R breaks this already. The thing -R points to is a "particular operating system instance". > > Assuming the package dependency system will tell you, and that the > dependencies are accurate and meaningful. Yeah, if the package declarations lie, there's not much the package system can do to help. (There are some special cases, like the way RPM automatically builds in dependencies to referenced shared library packages. For packages shipped with Solaris, we do a similar check at integration time. Generating dependencies like that would be a good function for future easy package generation tools.) > Ignore the package > system for the moment, why isn't there a way of telling whether > a software package is really in use (or when the binaries or > shared libraries in it were last used Well, that's pretty much solving the halting problem -- how can one statically analyze a bunch of executables to show they never will reference a given other object? - I tend to look at last > access times Sometimes in the real world we're stuck with that, of course. (I do remember getting bitten years ago by a bunch of application binaries that ran only once every not-quite-four-years based on an internal calendar system.) > >> The hard problem here is basically referential integrity. Once a >> domain is registered, nothing keeps the domain creator from >> destroying the domain without updating the registry. > ... >> One way to preserve referential integrity is to control domain >> creation and registry by having both done by the same process. >> People who want to do this already can -- the N1 System >> Provisioning System is a product which does it, and many big data >> centers have developed their own provisioning systems. But that >> approach is completely incompatible with the ad-hoc nature of our >> developer install use case. > > Yes, but the two use cases are sufficiently different that > different solutions are likely to arise. But as Darren pointed out, we really want one solution so application creators don't have to ship two different formats, and we don't have to create multiple update methods. > > As I see it, software domains have to be delegated from the > centre, rather than letting any user randomly create themself > a software domain at any time of their choosing. > How far do you think this has to go? If I create a software domain on a system I own, tar it up and untar it into a directory I can write into on another system, does the second system refuse to run that software? Rich
