Philip Brown <[email protected]> writes: > 2011/2/11 Maciej Bliziński <[email protected]>: >> 2011/2/10 Philip Brown <[email protected]>: >>> 2011/2/9 Maciej Bliziński <[email protected]>: >>>> 2011/2/10 Philip Brown <[email protected]>: >>> 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. > > that in itself, should be a sufficient example. > However, I have been told by people who know berkeleydb better than I, > that you also need the version-specific utilities (binaries) because > of differences in the underlying 'database' format between versions.
What you describe it's folklore, myths and legends, not a real example. >> 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 ... > > All my comments are predicated with [when it is determined that it is > *neccessary* to have a subprefix]. > I am not saying it is always necessary. I am only saying that *when* > it is, that certain things should then be done. > So please stop derailing the discussion by going back to [we 'also' > need to find out if it is neccessary] > > >>>>> 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. > > meaning, you dont wish to be seen as impolite. But you ARE saying you > dont believe me. I'm saying that I don't believe you. I will believe you when you give a concrete example and not some folksy reminiscences. > >> 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. > > Lots of things are "possible", without being easy to do. I've compiled > hundreds of pieces of software. You're asking me to go through all of > them, for the reason that you cant show me professional courtesy and > respect, by taking my word for it that I've hit this? Nobody asks you that. What we ask is a concrete example. Respect and courtesy are not arguments by themselves. >>> 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. > > its close enough. you are at minimum suggesting a list of "approved > tools", outside of which, we should ignore other tools. Nobody has suggested something like that. This is a distortion of reality. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
