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 -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | 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
