In message <[EMAIL PROTECTED]> you wrote: > ... > If we use the "/usr/packages/*" method, though, we can separate >installation into two steps. The maintainer supplies normal install >scripts that handles everything under "/usr/packages/<package-name>/". >It runs as, say, user "tool", group "bin". After that's finished, a >separate, *standard*, Debian-provided script runs (as root) that sets >up the symlinks, and changes the ownership of >"/usr/packages/<package-name>" to, e.g., "bin:bin". (Or "root:root", >or "<package>:dialout,dip", or whatever is needed.)
Aint that simple -- the standard debian-provided script released yesterday has to know how to handle a new package I will release tomorrow. So we need to wait for the new version of the script, then ppl can install my new package, report bugs, then I release a new version, then we wait for the new version of the script etc. Multiply by slightly more than 1000, which is the current number of debian packages. Ok, the alternative is that the script uses the information provided inside the package, which is precisely what we have now and the only benefits of your scheme is a different (read non-standard) directory structure and heaps of symlinks -- waste of [nowadays cheap] disk space, possibility of symlinks pointing to unmounted filesystems, [ add more here ] ... And don't tell me I can't exploit the script to screw up people's systems: it has to modify at least /etc, in addition to changing symlinks (unless of course we move all the configuration files from /etc -- nice thing about standards is that we don't have to follow them.) "Aieee, /vmlinuz is a symlink pointing to /usr/kernel-image/vmlinuz, but /usr is not mounted! Not a good day to die!" ... > Yes, there are exceptions. Indeed. Eg. all packages that have system-wide config files have them in /etc. ... Dselect and dpkg can be set to >prompt, "This package requires a script to run as user "root". Do you >want to [e]xamine the script, [r]un it, or [a]bort installation?" Read: "do you want to suspend dselect, su to root and continue?" "Do you want to suspend dselect, login as root, install and configure su and then continue?" "Do you want to do all of the above, go learn Perl, examine the script and _then continue?" Oh [EMAIL PROTECTED], why didn't I run dselect as root in the first place? Where's my nearest RedHat mirror? ... > This does require revision of dpkg, dselect, and the .deb format. And in the end, we will still rely on the very same thing -- that people involved didn't insert malicious code in the package, and that bugs will be soon found by us users, and promptly corrected. Your scheme simply removes debian package maintainers from the list of "people involved". Since I kinda trust them (have since .93R6), I don't think it's worth the hassle. Regards -- Dimitri reply to emaziuk at curtin.edu.au --------------------------- Avoid reality at all costs.