On Mon, 13 Dec 1999, Julian Gilbey wrote:
> On Sun, Dec 12, 1999 at 11:34:23PM -0800, [EMAIL PROTECTED] wrote: > > Disclaimer: IATTIMS > > ?? > > > On Mon, 13 Dec 1999, Julian Gilbey wrote: > > > Your package should make no assumptions about the existence of > > > /usr/local; it's entirely at the discretion of the sysadmin what to > > > put there. *If* there is an appropriate file there, it should be used > > > in preference/addition to the one in /usr, but your package must > > > function perfectly without it. > > > > Hmmmm. Package makes the assumption that it can load the server for any > > datasets stored under /usr/local/games/<package>/<foo>/ > > I'm not sure what you mean by this. What's a "server" in this > context? It's fine to make use of things under /usr/local, of course. It acts like a monolithic user-spawned daemon. Sort of [snip] > However, I don't know that much about your package: Why is it > necessary to set up local datasets? Why can the package not have > sensible default datasets? Might individual users want different > datasets? What happens during an upgrade if the format of the > datasets changes as you're not meant to touch stuff in /usr/local > automatically in general? It's a game server. People have user accounts stored in the dataset that can be created and saved at runtime. The server binds the dataset to a specified port or range of ports in high port space (generally anything over 2000, depends heavily on local policy) The 'sensible default' set only consists of two objects; the dataset itself and an account for the set administrator. The 'default' is meant as a sort of `master template' for an administrator to copy and customise. > > > Configuration files *must* go in /etc and be marked as conffiles or > > > otherwise handled carefully (see policy (version >= 3.1.0.0) section 4.7). > > > > Okay. You're not saying that any configuration-like files the server uses > > internally must go under /etc, do you? :> > > If they're intended to be modifiable by the sysadmin, then yes. I > guess that datasets do not come under this category. Why can't you > have the default data in /usr/games and a file in /etc to select the > particular data to be used? Again, though, I know nothing about your > package. What if it's something to be modified by a user without root privs, and by necessity must have a one-to-one correspondance with the set of datasets? The author's current system has all the configuration hard-coded in the init file. I'm working out a more portable method of supporting multiple instances and a much saner startup script basically written from scratch. The current idea is to have local policy set by the administrator in /etc/<package>.conf, and to have the individual datasets' configuration metadata stored logically with the datasets in (/usr/local/games/<package>/<foo>/,~<user>/.<package>/<foo>/) I do not see any way of arbitrarily supporting n distinct files in /etc/<package> and mapping them in any sane way to the above dirs while keeping the intended access privs. This seems to be the main sticking point right now. I think my understanding of terminology is slightly different than the manuals' explicit understanding. Perhaps I should post an example to this list? > > > You need to also look at policy, in the debian-policy package, and at > > > the Filesystem Hierarchy Standard, found in the debian-policy package. > > > Easy, isn't it?! > > > > Will have another look. I admit some bits are confusing even after the > > second read-through. > > Please file bug reports about the confusing things so that we can try > to clarify them. Can I file bug reports against my teachers and professors about using terminology slightly different that how it appears in the manuals? :> [snip] Thanks for all the help, guys. -- Ferret no baka
