Re: tar files in example dirs
joost witteveen wrote:
>
> Ah, now I see your problem.
Good.
> But usually, the right place never is /usr/doc, as usually nothing in
> /usr/doc gets used by the system (it's only there for the admin).
I thought /usr/doc is also for the admin, but mainly for the user
information.
>
> But for example in nfsroot, I've got an example of how to setup
> a printerserver. This pringerserver needs some ten files to
> setup (samba etc). These files all need to go into /etc, of cource.
>
> Now, the problem with me putting all those files in /etc is that:
> - they need to go into /etc/nfsroot/$IPNUMBER/
> and I don't know the $IPNUMBER of the clients the user is going
> to create.
> - I assume most people don't want to make printerservers.
> If I were to put those files in, say, /etc/nfsroot/default, then
> every client will by default have that setup. This is not ideal.
> So, I have to put those files in /usr/doc/examples.
Well, firstly let me repeat that I wasn't talking about your example (I
hear this for the first time), but about tarballs containing example
files for user's info).
Your problem: I could think of several approaches (not very well
studied):
- put files in /usr/lib/<package>, create a /usr/sbin script that
asks for a $IPNUMBER and let the admin use it to create the /etc
thing.
- make a question in the postinst and do the thing at installation
time (not my preferred solution)
- create a saparate binary package depending on the main package,
maybe call it "printserver", mainly to build the /etc thing. This
package could use both the methods above, and maybe also check
some /etc file or env var looking for the value during
installation/upgrade (to avoid the question in postinst if the
user supplied value is available). I don't know if there is a way
to register the new files as conffiles during postinst (that would
be the best thing IMHO).
>
> Of cource you can still argue that I should have untarred the
> .tar.gz in /usr/doc/nfsroot/examples myself (in the debian/rules
> binary).
Humm, I argue. :-)
And maybe the simplest thing would be to supply a makefile to install
the thing (this is the same as the first idea above, just simpler).
> I argue that this will only create more subdirs, more mess.
/usr/doc is already incredibly crowded (and maybe would be good if
someone could come out with an idea to reduce or organize this thing: I
could imagine a separation between package's standard info (copyright,
changelog ...) and the user's docs (text and html) like what we do for
man and info).
> and I would like to be allowed to give the user a .tar.gz file.
But I was under the impression that you should be able to _navigate_
/usr/doc using less or some other simple "reading" tool like lynx or
cat, and tar isn't exactly a reading tool, mostly for a newbie.
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
Reply to: