Andrei Popescu wrote: > On Mon,06.Apr.09, 13:21:49, Barclay, Daniel wrote: >> Andrei Popescu wrote: >>> On Mon,06.Apr.09, 12:52:02, Barclay, Daniel wrote: >>> >>>> Debian packages should have some standard place to go to to see those >>>> latter kinds of information. If it did, that place could also hold >>>> an indication of any daemons started (or installed but pending further >>>> configuration) by installing a package. >>> Sounds like /usr/share/doc/<package>/README.Debian to me. >> Maybe, if it can be somewhat structured or auto-generated. > > Auto generated from what?
From whatever contains any structured information to be read and added to README.Debian files if they remain partly non-structured as they currently are. The package contents can be obtained with dpkg. That lists only the uninterpreted, raw list of files. It doesn't distinguish between entry points vs. other artifacts, say: - commands meant for the user to execute vs. helper executables - root info files (command.gz) vs. associated ones (command1.gz, command2.gz) - commands meant for the user to run vs. daemons started automatically > >> > Ok, many of them could be improved, ... >> >> Exactly. >> >> First we'd need a standard or some guidelines about what should be in there. > > It would be quite difficult to write a guideline that would fit for both > samba and mpd. What kind of guidelines are you thinking about? I'm thinking of things like: Include a "Daemons started:" line listing any daemon(s) started by installing the package. How would something like that not fit virtually every package? (Yes, guidelines for pointers to documentation _might_ be a little harder to make fit all packages, since some have mostly just a manual page, some have many manual/info/etc. pages, and some packages are just documentation for something else.) > Rather file bugs (preferably with suggested wording or > even a patch) where you think it's necessary. Oh, come on. Wait for each instance of the problem instance of trying to work out a system (e.g., guidelines/standards) to avoid the problem in the first place? > I usually find enough information in there to know were to look further. The user shouldn't have to dig for some of this information, especially not in different forms in different packages. Daniel -- (Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
