Re: libexecdir

2005-10-18 Thread Justin R. Knierim
Randy McMurchy wrote: What exactly got installed in /usr/libexec. Not BLFS packages, right? Right, not a BLFS package. I believe it was courier-imap. No big deal, I know how to fix it now and will do when I rebuild lfs on it someday. And if not, then this is something you'll need to tak

Re: libexecdir

2005-10-18 Thread Randy McMurchy
Justin R. Knierim wrote these words on 10/19/05 01:08 CST: > I have had a /usr/libexec full of junk from a few programs I didn't beat > into shape, and I didn't care for it. Having it all sorted nicely in > /usr/lib/packagename I like. IMO. What exactly got installed in /usr/libexec. Not BLFS

Re: libexecdir

2005-10-18 Thread Randy McMurchy
On Wed, 2005-10-19 at 00:18 -0600, Archaic wrote: > /usr/lib : Alternate format libraries (optional) > Purpose > > /usr/lib performs the same role as /usr/lib for an alternate > ^ > binary format, except that the symbolic links /usr

Re: libexecdir

2005-10-18 Thread Archaic
On Wed, Oct 19, 2005 at 01:13:00AM -0500, Randy McMurchy wrote: > > That's because they qualify it as /usr/lib. > > being anything. It would be whatever you want, I suppose. Ahh, I see where you are coming from now. I think there is a misunderstanding. /usr/lib : Alternate format libraries (o

Re: libexecdir

2005-10-18 Thread Randy McMurchy
On Wed, 2005-10-19 at 00:11 -0600, Archaic wrote: > Sorry for how that must look. I understood what you meant, and knew immediately it was a typo. :-) -- Randy rmlinux: [bogomips 3923.96] [GNU ld version 2.16.1] [gcc (GCC) 4.0.1] [GNU C Library stable release version 2.3.5] [Linux 2.6.12.6 i68

Re: libexecdir

2005-10-18 Thread Randy McMurchy
On Wed, 2005-10-19 at 00:05 -0600, Archaic wrote: > On Wed, Oct 19, 2005 at 12:59:12AM -0500, Randy McMurchy wrote: > > > > I'm not sure that there is a real effect where these programs are > > installed. > > I was explicit enough. The effect I was referring to was cohesion > between the books, n

Re: libexecdir

2005-10-18 Thread Archaic
On Wed, Oct 19, 2005 at 12:05:12AM -0600, Archaic wrote: > > I was explicit enough. The effect I was referring to was cohesion s/was/wasn't/ Sorry for how that must look. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linux

Re: libexecdir

2005-10-18 Thread Justin R. Knierim
Archaic wrote: Looks like /usr/lib/packagename is recommended. +1 I have had a /usr/libexec full of junk from a few programs I didn't beat into shape, and I didn't care for it. Having it all sorted nicely in /usr/lib/packagename I like. IMO. Justin -- http://linuxfromscratch.org/mailman

Re: libexecdir

2005-10-18 Thread Archaic
On Wed, Oct 19, 2005 at 12:59:12AM -0500, Randy McMurchy wrote: > > I'm not sure that there is a real effect where these programs are > installed. I was explicit enough. The effect I was referring to was cohesion between the books, not the usability of the software. > FHS says /usr/libexec is ju

Re: libexecdir

2005-10-18 Thread Archaic
On Tue, Oct 18, 2005 at 11:56:53PM -0600, Archaic wrote: > > Looks like /usr/lib/packagename is recommended. But /usr/lib/sendmail is required, so we it looks we should take FHS with a grain of salt. -- Archaic Want control, education, and security from your operating system? Hardened Linux Fr

Re: libexecdir

2005-10-18 Thread Randy McMurchy
On Tue, 2005-10-18 at 23:42 -0600, Archaic wrote: > I like /usr/lib/packagename. Either way, this will have a far reaching > outcome and should be discussed by both lfs and blfs. I'm not sure that there is a real effect where these programs are installed. If you pass --libexecdir=/someplace/nobod

Re: libexecdir

2005-10-18 Thread Archaic
On Tue, Oct 18, 2005 at 11:42:51PM -0600, Archaic wrote: > > /me wanders off to pathname 4.7. /usr/lib : Libraries for programming and packages 4.7.1. Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts

Re: libexecdir

2005-10-18 Thread Shane Shields
Randy McMurchy wrote: Hi all, More and more, I'm feeling that the libexecdir that is typically changed to /usr/sbin shouldn't be. Most of the programs installed into /usr/sbin because we pass --libexecdir=/usr/sbin to the configure script are not designed to be run from the command line, or

Re: libexecdir

2005-10-18 Thread Archaic
On Wed, Oct 19, 2005 at 12:37:38AM -0500, Randy McMurchy wrote: > > What say the group? > > Do programs that are not designed to be run by end users (not even > the root user), but instead are called internally by a library or > other program belong in /usr/sbin? I like /usr/lib/packagename. Eit

libexecdir

2005-10-18 Thread Randy McMurchy
Hi all, More and more, I'm feeling that the libexecdir that is typically changed to /usr/sbin shouldn't be. Most of the programs installed into /usr/sbin because we pass --libexecdir=/usr/sbin to the configure script are not designed to be run from the command line, or for that matter, not desig

Re: Problems stopping nfsd

2005-10-18 Thread Bruce Dubbs
DJ Lucas wrote: > Okay...my previous suggestion absolutely sucked using killdelay. Thanks > for the 70 second warning Bruce. BTW, HUP seems odd to me, but I'll > know about that in a short time. I just can't help but think that > Nathan I talked about that script at one time or another, but can

Re: Problems stopping nfsd

2005-10-18 Thread DJ Lucas
Bruce Dubbs wrote: >> >>OK, I've validated your problem. Try editing nfs-server to change the >>relevant portion of stop to: >> >>#killproc nfsd >> >>kill -HUP `pidofproc nfsd` >>evaluate_retval >>sleep 10 >> >>And see how that works for you. If it works, the proc

Re: ROX

2005-10-18 Thread Alexander E. Patrakov
Andrew Benton wrote: Another application I'm keen on is the file sharing application gtk-gnutella. Filenames are an issue there as people on the network could be in any locale. There was a long thread on the gtk-gnutella-devel mailing list about language issues. I read it, but I don't pretend