Re: /usr/local (again)
From: Stuart Lamble [EMAIL PROTECTED] Just a suggestion (and probably not a very good one): where a package needs to ask a question, perhaps it'd be appropriate to have a script postinst.questions (or some such) which can be run after all the other packages have been installed and configured? Another possibility would be to have a script that runs immediately when you select the package using dselect, before the package is unpacked, and squirrels away your input for later. Of course, we'd have to run it from dpkg if dselect was not used. Discussion, please? Thanks Bruce
Re: /usr/local (again)
Bruce Perens: Another possibility would be to have a script that runs immediately when you select the package using dselect, before the package is unpacked, and squirrels away your input for later. Of course, we'd have to run it from dpkg if dselect was not used. Discussion, please? I'd like some (easy) way of storing answers to questions. The questions and answers could be shared between packages, when suitable. One such question would be whether the local admin wants to allow creation of the empty directories in /usr/local. If we want to be ambitious, we'll create a fancy language for defining the user interaction. Something similar to dialog, but something that is not tied to text terminals, so that it can later be extended to X as well. It's a big project, of course, and not something that should be undertaken lightly. Getting answers to these questions before unpacking anything would probably be a good idea. -- Please read http://www.iki.fi/liw/mail-to-lasu.html before mailing me. Please don't Cc: me when replying to my message on a mailing list. pgp9sdIfbBVdS.pgp Description: PGP signature
Re: /usr/local (again)
I'd like some (easy) way of storing answers to questions. The questions and answers could be shared between packages, when suitable. One such question would be whether the local admin wants to allow creation of the empty directories in /usr/local. If we want to be ambitious, we'll create a fancy language for defining the user interaction. Something similar to dialog, but something that is not tied to text terminals, so that it can later be extended to X as well. It's a big project, of course, and not something that should be undertaken lightly. I know that the Linux kernel has already solved that problem with their configuration setup programs -- they have three interfaces (text-based, curses based, and Tcl/Tk based) running off the same script, to generate the configuraton file. It also allows you to edit the configuration using the same tools, by reading and parsing its own output. It also allows the definition of arbitrary complex things and has the ability to handle interactions between items. Could this be adapted for our needs? It might not be perfect, but it -is- a start. Some modifications I could see being necessary would be to create a way of handling separate config scripts for each package that need them, and a few other minor issues. Getting answers to these questions before unpacking anything would probably be a good idea. This is useful for global options (what to do with /usr/local, for instance), but what about package-related options? Or are we thinking of two separate (but related) problems? -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice
Re: /usr/local (again)
Dear Bruce, you wrote: Let's please not add unnecessary questions in the postinst. I think /usr/local should be a symbolic link to /local, but it should always exist. We will not gain anything with this! I am sure if you think about it you will recognize that this will just shift the problem to a different location in the file system. On all my Linux systems /usr/local is a mount point of a READ-ONLY AFS or NFS volume. And we have our own site-wide /usr/local structure which is shared by all 12 architectures. As it stands right now, Debian is not well-behaved in a heterogenous environment. Please take a short time to consider the arguments of others and credit them with some intelligence and experience. My proposal resulted from several years of experience fitting Linux systems into an existing network. The bottom line is: no package shall ever make any assumption about anything regarding /usr/local. If that package needs a COMPILE TIME definition where local files reside, my proposal is a reasonable way to avoid hacking the sources. Dominik =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht mlAFS file/A access.
Re: /usr/local (again)
Bruce: Let's please not add unnecessary questions in the postinst. I think /usr/local should be a symbolic link to /local, but it should always exist. From: Dominik Kubla [EMAIL PROTECTED] We will not gain anything with this! I am sure if you think about it you will recognize that this will just shift the problem to a different location in the file system. On all my Linux systems /usr/local is a mount point of a READ-ONLY AFS or NFS volume. And we have our own site-wide /usr/local structure which is shared by all 12 architectures. As it stands right now, Debian is not well-behaved in a heterogenous environment. Please take a short time to consider the arguments of others and credit them with some intelligence and experience. Ouch! What I object to is another question in the postinst. I installed several Debian systems last week, and there were too many questions - the effect was that you could not let the installation run unattended. What's worse, some maintainers have placed questions in the pre-install script - and then you get questions all during the installation instead of just at the end. So please figure out how to do this with adding a question to every package that uses files in /usr/local. Thanks Bruce
Re: /usr/local (again)
Hello Ian, you wrote: In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in /usr/local by supplying it in the filesystem archive for unpacking by dpkg. The /usr/local directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by root.staff. I diskussed that with Richard in private email earlier and what i proposed was: 1. Provide a link /usr/lib/package/local pointing to /etc/local/package. (One might as well use /etc/alternatives ...) 2. At installation time ask the installer where the local directory is located and make create a link /etc/local/package to the location given by the installing person. Thus there is a well-defined path at compile time which is configurable at run-time. The reaseon for the redirection through /etc is the support of read-only media (CD-ROM or NFS-shares). Comments? Dominik Kubla =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht mlAFS file/A access.
Re: /usr/local (again)
Richard Kaszeta writes (/usr/local (again)): ... Since packages generally don't install anything other than empty dirs in /usr/local, can't this be handled in a way that makes it easier for those of us trying to maintain many debian machines? Section 3.2.9 of the policy manual may be informative. I haven't implemented the required feature for dpkg yet. Ian. 3.2.9 /usr/local - for the use of the system administrator As mandated by the FSSTND no package should place any files in /usr/local, either by putting them in the filesystem archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. Every package that searches a number of directories or files for something (for example, looking for shared libraries in /lib or /usr/lib) should search an appropriate directory in /usr/local too. In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in /usr/local by supplying it in the filesystem archive for unpacking by dpkg. The /usr/local directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by root.staff. In the future it will be possible to tell dpkg not to unpack files matching certain patterns, so that system administrators who do not wish these directories in /usr/local do not need to have them.
/usr/local (again)
Just an idea, no flames, etc intended: Could maintainers who have packages that create directories/etc in /usr/local make sure they do it in a way that is friendly to nfs-mounted /usr/local? Example: On all of our debian 1.1 machines, /usr/local is an nfs mounted directory, and on all but one of these machines it is mounted root-squash for security reasons. Attempting to install packages with components in /usr/local (usually empty directories) fails on these machines: bash# dpkg -i emacs* (Reading database ... 23142 files and directories currently installed.) Preparing to replace emacs (using emacs-19.34-1.i386.deb) ... Unpacking replacement emacs ... dpkg: error processing emacs-19.34-1.i386.deb (--install): failed to rmdir/unlink `/usr/local/lib.dpkg-new': Permission denied Setting up emacs-el (19.34-1) ... Errors were encountered while processing: emacs-19.34-1.i386.deb Since packages generally don't install anything other than empty dirs in /usr/local, can't this be handled in a way that makes it easier for those of us trying to maintain many debian machines? -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
Re: /usr/local (again)
Richard Kaszeta writes: Just an idea, no flames, etc intended: Could maintainers who have packages that create directories/etc in /usr/local make sure they do it in a way that is friendly to nfs-mounted /usr/local? I second that! AMOF i did bring that up some time ago, but somehow we couldn't find a common policy. Dominik =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.htmlAFS file/A access.
Re: /usr/local (again)
I sort of thought we had settled on (a). Although I would normally expect /usr/*local* to be local, I don't see any reason not to be friendly to unusual setups especially in the case of (c) where it doesn't cost anything, assuming the base package puts in a reasonable default. Well, in my case it is local, as in local to the site. On many unix installations it is not uncommon for /usr/local to be a nfs mount. Besides, aren't we supposed not make assumptions about /usr/local at all (according to FSSTND/FHS)? -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
