I see a couple of problems: >From a users perspective the clourisation option for ls will be close to useless, as almost everything under /usr will be pale blue. I think that ls will have to be modified to set the colour based on the links source - but then how do you identify the symlinks that you want to be blue? Yes, the -F option will still have an @ for symlinks, but is this how ls picks it's colours? I leave this to my betters to consider.
The other one may be just a problem due to my personal laziness. I like to take some binaries, mv then to old_name.dist, chmod then to 750 and put a little script undr the old name explaining why users can't use binaries they expect to be useable (a slightly fascist approach, but at least I'm polite enough to let them know why!). I assume that the /usr/packages/* would be meant to be modified by dpkg and the install scripts, and not by me (so as to not break too much!). Symlinks inherit the permissions of the source, so I either have to break the link ihn such a way as to find it again, or modify the permissions in /usr/packages/*, or dpkg has to know a way to deal with this scenario so that my heavy-handed approach is reversible. For example, until the INN thing is fixed, all the newsreaders on my machine are disabled, and a script displays an explanation why to my users. I'll undo this once the /bin/sed thing is fixed. I understand the security/certification issue, but it somehow reminds me of when I used Slackware - "You are in a maze of twisty little symlinks, all alike". John Foster.
