Re: [bug-inetutils] some notes on inetutils-1.8

[melodramus]

On Tue, 17 Aug 2010 17:29:54 -0400
"Alfred M. Szmidt" <address@hidden> 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 <address@hidden>