On Thu, Dec 02, 1999 at 03:41:34PM -0800, Joey Hess wrote: > * "Every package must have exactly one maintainer at a time." This statement > is violated by so many packages (including dpkg) that it should be removed.
I think it's being interpreted as "one maintainer email address". But you're right, the language should be cleaned up, as in a number of cases that email address is a mailing list. > * This seems self-contradictory. Are you supposed to remove the created > directories or not? > > However, the package should create empty directories below > `/usr/local' so that the system administrator knows where to place > site-specific files. These directories should be removed on package > > removal if they are empty. > > Note, that this applies only to directories _below_ `/usr/local', not > > _in_ `/usr/local'. The directory `/usr/local' itself may only contain > > the sub-directories listed in FHS, section 4.6. However, you may > create directories below them as you wish. You may not remove any of > > the directories listed in 4.6, even if you created them. I think this means that if there's a /usr/local/lib and you respect a /usr/local/lib/gobble then you should create this directory. But if /usr/local/lib doesn't exist you shouldn't. > * "must not overwrite or otherwise mangle the user's > configuration without asking, must not ask unnecessary questions > (particularly during upgrades), and otherwise be good citizens." > > Just to remove the tiny shred of ambiguity from this sentance, I'd say > change the end to "and must otherwise be ..." In my opinion, that's a worthwhile bit of ambiguity. Basically, it's asking for no pathological behavior. And that's all too easy to do with automated handling of configuration files. > * "Do not arrange that the system administrator can only reconfigure the > package to correspond to their local security policy by changing the > permissions on a binary. Ordinary files installed by `dpkg' (as opposed to > conffiles and other similar objects) have their permissions reset to the > distributed permissions when the package is reinstalled. Instead you should > consider (for example) creating a group for people allowed to use the > program(s) and making any setuid executables executable only by that > group." > > This paragraph seems to be unaware of suidregister. Perhaps it should > mention it as an alternative. Hmm... Points to consider: (1) suidmanager is optional, (2) dpkg doesn't directly support suidregister (3) using a consistent scheme (group access, in this case) has other nice properties. However, it is worth thinking through. Good work, Joey. -- Raul
