On Thu, Feb 14, 2008 at 03:56:19PM -0800, Philip Brown wrote: > blastwave does not currently have a twiki package. This comes to mind, > because of my recently having to deal with a similar software installation, > by hand, and thinking "wouldnt it be nice if I didnt have to do this by > hand, but I just had a package to do it for me".
Do you really want the package to do it for you, or do you just want the thing to work by the time you get to start using the software? If it's the latter, then why does it matter if the package does the work or if the software does it when it realizes that it needs to be done (either by being told, by looking for itself, or by starting up for the first time after install/upgrade)? But certainly, the less the end-user has to do for the software to just work, the better. > > So you're asserting that the packaging system, running as root, or under > > the Software Administration profile, is going to have the necessary dba > > perms, passwords, etc? > > Sometimes it does. For the software I upgraded recently (the recent one, may > not have been 'twiki' specifically), it was sufficient to "run this stuff as > root". no special passwords were required. it was to a local mysql database. But it would not have worked for the service that started twiki to make the necessary mods? If no passwords were required, then presumably any user which could connect to the database could do what was needed, no? > I will simply say, that the more popular linux distributions, take the > opposite view: that the purpose of "the package", is to install, > configure, and make functional, the desired software, in a completely > automated fashion, as much as possible. > > THAT, is what makes linux popular!! There are dozens of reasons that linux is popular. That software delivery is conflated with software configuration, if it is one at all, is, I'm pretty sure, low on the list. > I recently had an encounter with a sysadmin, who normally runs on solaris, > but set up a new service on linux... *specifically* because he didnt have to > do any tweaking.. he just did [foo install software], and it was all set > up, running, and ready to go. I'm not arguing that the end result should be any different on Solaris. I've not once said that the end-user should have to do more work. I have said that the software developer who wrote the component the end-user is installing might have to do more work, but I don't think it's much work, and I'd rather place the burden on him, anyway. I'd be happier to centralize the burden even further, but postinstall scripts don't do that. Our non-filesystem actions do, though. And there may be other OS-level improvements that could be made to simplify the world, too. > To make the solaris experience as pleasant as the linux experience, the > extra automated handholding, must be done by "the packager". Yes. > As such, it seems to me to make the most sense, to give "the packager" the > maximum amount of flexibility and power, in "the packaging tools and > framework". You can trim your roses with a chainsaw, too. I wouldn't recommend it. But to make a closer analogy, if you never have the need to cut trees down, then why should you need a chainsaw? All you need are a pair of clippers, maybe a hedge trimmer. Or a gardener. > Ironically, i seem to recall that, just a few months ago, someone on this > very list was complaining about "the evils of layering", and how tight > integration was far preferable (the ZFS architecture example). Seems to me, > that attitude would mandate "tight integration" of things that packagers > need to do, into "the packaging system". You can't paint every situation blindly with the same brush. Layering has its uses, but when increased information flow allows subsystems to make more accurate and automatic decisions, that's usually a benefit. I don't see such a situation in packaging, and I don't think you've even tried to make that argument. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
