On Tue, 17 Aug 2010 17:29:54 -0400 "Alfred M. Szmidt" <a...@gnu.org> wrote:
> No, libexec/ is the `traditional' place for daemons. They aren't user > programs, thus have no place in /bin. for the fun of it, i installed the old netkit-combo package to tmp and found that _all_ the daemons were placed in sbin. libexec wasn't used. > > The FHS isn't tradition though, they actually broke it. Where we > install programs predates the FHS by A LOT. I'd suggest that you stop > claiming tradition as a basis for your arguments, since they have so > far been wrong. tradition is what lives on, not what got dropped. what you talk about is history. i don't know the good practice of the 70s, but much of it became bad practice and was mainly unknown in the 90s, as i started with linux. i don't mean the libexec folder (which i already commented on) but that it was the place for daemons. fhs, instead, is today's good practice. possibly it is still not tradition, but it will be. > in further other words: re-think your position because it is not > standard conformant (like libexec itself) and does not reflect > common usage. > > It is what is standard, and traditional on GNU and has been for the > past 20+ years. And that is the system that we develop for, you can > easily install the daemons elsewhere if it doesn't suite your needs by > using the --libexecdir option. i have no idea what you are talking about. where do you get this 20+ knowledge from? on my system, i installed 300+ packages (and quite half of that from the GNU project) from source and (speaking only about the path directives) only used --prefix and the documentation directives except of '--prefix=/usr --exec-prefix=/' in some rare cases. in other words: the software i installed ended in sub-directories chosen after the decisions of the package maintainers, not of myself. here is the result: /libexec syslogd from inetutils-1.8 the rest is only helper tools and scripts /usr/libexec gam_server (gamin, a file watcher) libacl.a libacl.la libacl.so -> /usr/lib/libacl.so libattr.a libattr.la libattr.so -> /usr/lib/libattr.so lots of helper tools (mostly for hald) some directories with secondary stuff /opt/.../applications/libexec xconfd (configuration backend from the xfce desktop project) evinced (from the, yes, GNU gnome evince document-viewer project) beside that only a handful of helpers .../gcc-4.3.3/libexec/gcc/i686-pc-linux-gnu/4.3.3/ cc1 cc1plus collect2 install-tools the other languages (except of smalltalk, having vfs modules in libexec), Xorg, firefox, webkit etc. didn't create a libexec directory in their main places. /usr/local/libexec, /opt/libexec or whatever other libexec folder is not existing on my system. in other words: libexec is used for whatever but a daemon. following fhs , lib<qual> should only be used for libraries of different binary formats like in lib32 and lib64, but libexec is mainly used for not-a-pure-lib stuff. it should not exist (under that name), from my point of view. nearly all daemons on my system reside in sbin (and few in bin.) so where is the 20+ GNU tradition??? it's possibly a debian or a redhat tradition. that may be. however, as already written, GNU is a _guest_ on my linux/posix system and should behave right. > > > The -? option is quite often used in GNU implementations as a > > shorthand for --help, so there was no "breaking traditions" here. > > Try `tar -?', as an example. > > try sed -h and see how nicely a GNU tool can come along with good > rites (which doesn't forbid sed -? in parallel.) why so > separatistic??? i don't get the sense of this split. what is wrong > with -h that you discriminate its further use? is good habits and > practices, routine and normality, and all what makes the live of an > admin easier (especially in mixed environments) just worthless to > you? > > -h is an INVALID option to sed, so I fail to see your point. As a > administrator you'd realise that having -h output help in some > programs, and in some not would be frustrating, which is EXACTLY why > we picked -? as a short option since it does not conflict with any > other options used. ah, overlooked the first line. sed was so nice to do the right thing in first place ;) but the next try, bison -h, worked :) > Please stop attacking us in this manner, I asked you in private to > adopt a friendlier tone but this is simply enough. i'm not attacking you. i'm correcting your errors like you corrected mine above, with terms like INVALID and EXACTLY. i'm just talking about how it is and why your answers don't meet reality. if you can't stand this, you possibly should learn it because most problems with a project reside in the heads of the maintainers and not in the code. yes, so it is. reality is hard sometimes. if we can't debate about wrong views and attitudes, users of free source will have to accept their project maintainers as the remote sun gods of their home systems. this is a very bad situation you put your users in. wasn't free source about freedom? ah, sorry, that's like with bio and fair trade not talking about the same sustainability. do you know how often i wanted to just throw GNU/linux out of the window? do you know how often that was because of selfish and stubborn maintainers? far more often than because of bugs. bugs are annoying but nothing against this helplessness of being a user. the only reason i still walk through this mess of free source is that i otherwise had to go back to *dows or * osx (the traps.) however, if there ever comes up a nice and understanding 'no-geeks' community providing me with a second approach to free software (and system layout), i switch! best wishes, MeloDramus <melodra...@online.de>
