On Sat, 25 Jul 1998, Tim Rightnour wrote:
> Just because I installed a game, doesn't mean I want to play *right now*.

And just because you install a game, that probably means you don't want to
fiddle with some config stuff *later* if you want to play.

I don't say that adding some modules to a pkg should restart any
accompanying daemons etc., but _if_ you install a module, really make sure
that it is installed all the way and not do a half-assed job which the
user has to clean up after. 

This will at least for the most common cases. If someone wants to have
some special conditions for his setup, he'll find out how things work and
know what to do anyways. It's beginners that we need to make things easy
for.


> #  The deal if the pkg system was and is to make things for _users_ as easy 
> #  as possible. Introducing any additional manual intervention is bad.
> I don't mind things being easy for users.. heck.. I'm all for it.. I just would
> *really* like to stop the "surprise! your running mysqld as root on port 61!"

Well, and who said it to actually *install* mysqld in that case?
Sure if we only have 1 mysql package, it's difficult at install time to
tell it under which UID to run, but that's a different problem.


> And I *certainly* don't ever want to see apache go and run itself just because
> I installed it..  My ideal situation is this:

I never said to _run_ it.


> We either make the pkg interactive, and say "do you want to do this" or tell
> them, "run this to do this" then:
> add apache to /etc/rc.local
> do whatever else needs to be done to let the user have a working setup..
> run it (shiver) and *tell them it is running*

You can tell users lots of things, but be sure it will just piss them of.
Every information they have to compe with will likely confuse them.


> One of my big points here is security..  I can't personally vouch for the fact
> that there are no remote security holes in the default setup of mysql.  How do
> I know the act of it running, as root, and me not knowing it has launched off,
> hasn't opened my system up to a possible vulnerablity?  I don't mind that the
> program runs to test itself.. thats not only reasonable.. but a *good* idea to
> test things before saying "build is done".  But it certainly violates the
> principal of least surprise.

1. We provide binary pkgs compiled by only a few individuals to reduce the
   risk of security-surprises being introduced
2. If you're really concerned about security and you want to know what's
   going on inside some piece of software, you're free to UTSL. 
   The goal of the pkg system is to support beginners (well, rather) that
   want things going, without having to worry about 1000 things - what's
   what we have to care of, and also that's why I say add that lines to
   the right config files if you add some modules.


> #  Said that, someone should add some sane config files to our fvwm2 pkg, 
> #  and probably others as well.
> 
> You speak as if there are sane config files for fvwm2.  I can donate mine.. but
> It's probably highly me-centric. (I can get rid of a few things on it.. and
> make it at least useful if need be..  lemme know)

The deal is quite simple: install a new machine, pkg_add fvwm2, and see
what comes up. Add something _a bit_ better. I don't say add bells and
whistles, but again, any clueless user will see this at first after
setting up his machine, and it's the first impression that counts, no? 
If you add some pager that's not even well-aligned and that's too small to
have space for the bitmap in it, that looks highly suckt. That's what I
mean.

But maybe we want to have all this pkg-config-stuff in an extra pkg
(dotfiles? :)


 - Hubert


-- 
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>