HI Jan,
To be clear, I'm not advocating installing to /usr/lib instead or
/usr/lib64, my suggestion only pertains to the possibility of using
/usr/local/lib rather than /usr/local/lib64 as the later isn't
supported out of the box. As it turns out Madriva and at least older
versions of RedHat/Fedora + Debian don't even support search
/usr/local/lib out of the box, let alone /usr/local/lib64. Given this
it does rather blunt the advantage of installing in /usr/local/lib if
it only works with later debian/ubunutu combinations.
> With regards /usr/local/lib* being a standard place for locally
> installed libs - yes and no. Lot of especially commercial UNIX systems
> will install such software into /opt/foo/{bin|etc|lib*|share} hierachy,
> where foo is the name of the software, often including a version. Also
> a lot of admins do this (me included) - it makes keeping multiple
> versions of software and upgrading a lot simpler compared to a mess in
> /usr/local/lib after several pieces of software are installed. The
> downside is that you need to either make a lot of symlinks or handle
> PATH, LD_LIBRARY_PATH and similar a lot. I have seen also /sw being
> used in this manner. E.g. SuSE used to ship KDE installed in /opt for a
> while. Each method has its pros and cons.
So for the past half dozen emails you've been saying that
/usr/local/lib64 is the "standard", but... there are also all these
other standards...
Given all these difference ts there a common system for ld.so.conf.d
that we could leverage? i.e my suggestion of installing a
openscenegraph.conf that points to the installed directory would only
work if we knew that there was a standard place to put this file.
This does sound like a long shot.
> The usually recommended thing is to make things easy for the downstream
> packagers, they will deal with the distro-specific things for you. You
> cannot conceivably maintain packaging scripts or whatever for the
> hundreds of Linux variants out there, all with their own idiosyncrasies
> (e.g. Mandriva RPM spec file is not going to work on RedHat without
> changes and vice versa ...)
The question then is... how to we make it easier for these downstream
package maintainers.
It's also a two process - the package maintainers are typically rather
too disconnected from upstream development. I realise the is hard
given that maintainers are probably trying to cover many different
packages. While there are many hundreds of distro's there are ten of
thousands of packages. To me it'd make sense to leverage the original
software communities like ours to take responsibility for such package
management as at least we have more people in our
>> Any volunteers to do this :-)
>
> I can do that.
Thanks.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
