Re: How to handle multiple versions of binaries
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.
> According to how I read the packaging manual this is /encouraged/, AFA the
> package can function without anything actually being under /usr/local.
> I also intend to supply a script, to be run by the sysadmin, to assist in
> setting up a dataset in the abovementioned directories.
Sounds fine.
> AFAICT both functions are reasonable. Both /supporting/ the use of a
> directory under /usr/local if the local admin so wishes, and the supplying
> of a script to assist the admin in correctly configuring anything sie
> wishes to have under /usr/local.
Sounds helpful.
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?
> > 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.
> > 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.
> > If the dataset is architecture independent, as it probably is if it is
> > modifiable, then you should be using /usr/share/<pkg> and
> > /usr/local/share/<pkg> rather than the lib directories.
> >
> > What happens if the sysadmin installs the package and isn't interested
> > in customising it for the users? Is there a default dataset? Is
> > there a search path to look through?
>
> I'm intending to make the server a seperate package from the dataset(s),
> and to have a <package>-common package on the current assumption I'll have
> two seperate servers for a while.
>
> The init scripts will have an option to load any datasets found under
> certain users' home directories as well.
As long as this is controllable by the user, I would guess.
> So what it looks like at this point:
>
> Main configuration file in /etc/<package>.conf
>
> ELF binaries installed in /usr/lib/<package>/
>
> Wrapper script installed in /usr/bin/
>
> "default" dataset(s) installed in /usr/share/<package>/
>
> Init script checks in /usr/local/games/<package>/<foo>/ and optionally
> ~/<user>/.<package>/<foo>/ for valid datasets to load.
~<user>/...
> As far as I can tell at this point it looks about right. I'm not missing
> anything very major, am I?
Sounds fine. Good luck!
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: