2011/2/10 Philip Brown <[email protected]>: > This subdiscussion, is only relating to things that MUST have their own > prefix.
I am not entirely sure whether any software actually requires being compiled with a custom prefix. It's quite likely that every package currently compiled with a custom prefix, could be in fact compiled with --prefix=/opt/csw. Other steps can be taken to ensure compatibility with other versions of the same piece of software. > Certainly, if there are clean ways to compile it and install something > with prefix=/opt/csw we should do so. But we are talking about the > things that cannot. > For example, the multiple versions of berkeleydb. That we have to have > installed at the same time, and use as neccessary. It's not a matter > of "pick this one, to be the 'real/active' one" Are there two incompatible libdb-X.Y.so files with the same SONAME? If the answer is no, then BerkeleyDB can be compiled with --prefix=/opt/csw. >>... >> as Maciej has pointed out, it's >> valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib. >> One is more normal, agreed, but both are valid. > > In many cases, this works. In very rare cases, it does not. But that > side of things isnt really the important thing here. > > What I've written before in this very thread thread, but I guess I > have to repeat now, is that having the library detectable in > $PREFIX/lib is important, not so much for the program itself, but for > *other* programs that need to link with it. By $PREFIX, do you mean our prefix, or a different one? > Unfortunately, some software has really dumb configuration. it only allows for > --with-somelib=/install/prefix/here > NOT > --with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 > > Not having the shared lib visible in its expected place of > $PREFIX/lib, would require some other programs to be heavily patched > to compile it properly. > So, it needs some kind of presence in *both* /opt/csw/lib and > /opt/csw/PREFIX/lib I highly doubt this is the case. I haven't seen an example of source code which, configured with --prefix=/opt/csw, requires a library to be in /opt/csw/foo/lib, and can't be linked when that library is available through /opt/csw/lib. When a library is present in /opt/csw/lib, and the running binary contains /opt/csw/lib in RPATH, the library will always be found. All our binaries have /opt/csw/lib in RPATH, therefore all libraries in /opt/csw/lib will always be found. If there is a binary that needs OpenCSW libraries and does not have /opt/csw/lib in RPATH, it's a bug, right? >> If we start considering side effects as weighted factors when setting >> policy, we're doomed. > > If everything else is equal, then side effects are then useful to consider. > Functionally speaking, for achieving the goal of "allow use with > -L/opt/csw/lib", direction of symlinks doesnt matter. At that point, > the lesser side issues are fair play for a decision on which direction > they should go. While I agree with the general statement that if larger criteria are equal, considering smaller criteria is useful, I believe that the smaller criteria should be within the scope of our goals as the project. The output of "du -k" is not within OpenCSW's goals. If you would like to include the output of "du -k" in our policies, the proper way to do this is sending out a proposal. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
