Bug 969 - bugs/questions/complaints
bugs/questions/complaints
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: basesystem (Show other bugs)
5.2
All Linux
high Severity high
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-01-26 12:32 EST by kojima
Modified: 2014-03-19 07:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-03-18 14:28:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kojima 1999-01-26 12:32:38 EST
Hello,

My name is Alfredo K. Kojima and I am one of the developers
of a window manager called Window Maker. I'd like to make
some questions/complaints/flames about your RedHat 5.2
product:

- Why there are no symbolic links from cpp to a reasonable
place like /lib/cpp?

- Why isn't /usr/local/lib included by default in
/etc/ld.so.conf?

This is a major cause of confusion to users of programs they
compile by theirselves, including Window Maker. I get dozens
of email from RedHat users who have problems with this,
asking why they get a "libxyz.so not found" error after
installing Window Maker and running ldconfig, as our
documentation says.

- Why isn't /usr/local/bin included by default in the PATH
environment variable?

This is another cause of confusion and frustration for users
of programs they compile/install by their own. Many programs
that rely on the bin/ directory being reachable through PATH
simply don't work, as you know.

- Why /usr/X11R6/include is not searched by default by gcc?
Why the X development package does not create a symbolic
link from /usr/X11R6 to /usr/X11, which seems to be enough
to solve the problem?

- Why are you including a beta/alpha version of libtool
(libtool 1.2b) instead of the latest stable 1.2? Whoever
downloads libtool to install in their system normally gets
it from ftp.gnu.org and not alpha.gnu.org. Other Linux
distributions also seem to include libtool 1.2, rather than
1.2b. So it's safe to assume that libtool 1.2 is the
"standard" version of libtool for almost everybody who have
it installed, except of course, redhat 5.2 users.

We got a flood of email from RedHat 5.2 users having
problems with libtool because libtool 1.2b is not fully
compatible with libtool 1.2 The problem was actually a side
effect of a strange timestamp issue on our part, but the
results would not have been so bad if RedHat 5.2, which
seems to be the most used Linux distribution, sticked to
libtool 1.2, instead of a beta/alpha version.

I know RedHat is a big supporter of the free software
community, but this sort of issue is very distressing and
tiring for me. I am sure that I am not the only free
software writer who have been having these problems and the
number of RedHat users who had problems with Window Maker is
much larger than the number of help request email I got.

Please reply to this

--
Alfredo
Comment 1 David Lawrence 1999-03-03 16:51:59 EST
These suggestions have been assigned to a developer for further
review.
Comment 2 Cristian Gafton 1999-03-18 14:28:59 EST
1. there is a symbolic link /lib/cpp on the RH 5.2 system
2. FHS does not mandate it
3. /usr/local/bin is included in the default PATH.
4. FHS does not require that - moreover, it talks about obsoleting the
/usr/X11 crap.
5. Lots of programs require the new libtool. As you said, it was your
fault and not libtool's. We could not build a lot of the final code
releases in RH 5.2 without using the beta version of libtool (egcs is
one of those things that need an updated libtool)

So from all the issues raised here, the first one is not simply true
and the others are problems with the WindowMaker code and makefiles...

Note You need to log in before you can comment on or make changes to this bug.