Re: How to handle multiple versions of binaries
On Mon, 13 Dec 1999, Julian Gilbey wrote:
> On Sun, Dec 12, 1999 at 11:34:23PM -0800, ferret@phonewave.net 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
Reply to: