2011/2/10 Philip Brown <[email protected]>: > 2011/2/9 Maciej Bliziński <[email protected]>: >> 2011/2/10 Philip Brown <[email protected]>: >>> This subdiscussion, is only relating to things that MUST have their own >>> prefix. >>... >>> 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. > > sigh. > > Certainly the thing "can be compiled" that way. The problem is that we > need the FULL environment, to actually use it to compile things that > need it.
Can you provide a specific example? One piece of software that needs an old version of berkeleydb, is postfix. I've read its build recipe[1], which requires two elements: 1. Include files 2. The .so file (with its target) It does not require anything else. No other parts of berkeleydb-4.2 are necessary. It's just one example though, so I'd be interested if there is a piece of software which requires more than the two elements listed above. > Some "newer" progams, need "older" versions, not just "the > latest version" of berkeleydb. > We need the binary utils, and include files, etc. for that version all > present. > We need multiple versions installed, at the same time. > They CANNOT co-exist in the same namespace, there are conflicts for > almost every filename. Yes, there are filename conflicts. > Therefore, they must be delivered in their own subprefix. This is a non-sequitur. If file conflicts are present, there are two things to be done: 1. Find out whether older files are actually useful 2. If they are, either put them in a separate directory, or modify file names to remove conflicts Delivering in a custom prefix is a way of accomplishing point 2, but it's not the only way. > That being the case, either the maintainer has to do all kinds of > fancy post-build scripting to install the stuff expecting to be > installed directly under /opt/csw.... > Or they can just do the straightforward thing and compile with > --prefix=/opt/csw/berkeleydb-X > > I would submit to the readers, that the latter is far saner. There are two sides to it: building the library (say, berkeleydb) and building software that links to it. It may be easier to build berkeleydb itself with a custom prefix, but it makes it harder later on, for other maintainers to build software linking against it. >>> 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. > > Maciej, I'm not just talking hypothetically, I've SEEN this happen. to > my great irritation. with multiple pieces of software. > Are you going to take my word for it, or are you going to call me a > liar by insisting I provide "proof"? It is not possible for me to answer a question framed that way. I would like to discuss ideas, not people. > "I've never seen it" != "it doesnt exist". Agreed. The second part of the reasoning is: if it exists, it is possible to come up with an example. I believe it makes sense to examine evidence before forming an opinion. It would help to provide a scenario in which there's a need to provide a library outside of /opt/csw/lib even though it is already available in /opt/csw/lib. >> 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. > > you have no right to make that statement. Plus it is provably false anyway. > If something is a common user behaviour in Solaris, then it is "within > opencsw's goals" to support it, since our documented goals are to > provide "a straightforward, easy-to-use experience for the user" > >> 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. > > This is ludicrous. you are setting up absurd hurdles specifically > targetted to justify you ignoring this issue, with no other benefit. > > To treat it equally and fairly, would mean we would have to generate > an "officially approved list of user commands, with all 'approved' > command line switches". > And then if a user said, "well I use that command, with this other > switch", the maintainer could say "well sorry thats not on our > approved user command list, goodbye", which would be equally heinous. The argument above sets up and attacks a straw-man. I'm not suggesting anything about a list of approved command line switches. I'm suggesting that if the distribution of disk usage across directories under /opt/csw is a factor to be taken into account in our policy, it needs to be discussed and agreed on separately, before it can be used in policy making. Maciej [1] http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/postfix/trunk/Makefile?view=markup Lines 181-185 [2] http://lists.opencsw.org/pipermail/maintainers/2011-February/014094.html _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
