On Thu, 10 Jul 2008 09:23:10 -0700, Dan Thurman wrote:
> Michael Schwendt wrote:
> >
> > On Thu, 10 Jul 2008 08:16:28 -0700, Dan Thurman wrote:
> >
> > > Whoa!
> > >
> > > There is a clue: open("/usr/lib/alliance/lib/tls/i686/sse2/libc.so.6",
> > > O_RDONLY) = -1
> > >
> > >
> > > What this means is that package Alliance is somehow screwing things
> > up!
> >
> > Not exactly, but look at the "alliance-libs" package, which is the
> > culprit. It installs /etc/profile.d/alc_env.sh which plays with
> > $MANPATH for example. Re-review needed it seems.
> >
> > > Hmm... I think someone needs to ensure that the Alliance package needs
> > > to be
> > > re-examined as far as ensuring other programs do not break?
> >
> > http://bugzilla.redhat.com
> >
> I found out with testing, that csh works fine, but shell does not. The
> shell environment variables are not being setup/passed properly before
> the profile.d files are being run. I find that nearly all of the tests
> using
> -z flag are showing that environment variables prior to executing
> the profile.d files are empty, so hard-wired environment variables are
> being declared. It does not appear to be a problem with Alliance's
> scripts, rather it is something else "higher up", or so it seems.
The problem *is* with the Alliance profile.d script.
Fedora uses a default MANPATH as defined in /etc/man.config, and the
$MANPATH env var is undefined. Therefore the -z check in Alliance's sh
script is inappropriate, as it causes the script to set $MANPATH to
point to Alliance's manuals and override /etc/man.config.
Instead, the alliance pkg could append a MANPATH definition to
/etc/man.config and remove it again upon pkg removal.
"man man" explains how "man" searches for manuals.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
