On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote: > On 27 Jan 1999, Alexandre Oliva wrote:
>> Except that, if you replace the library with an incompatible one, you >> *are* breaking the contract. > We don't replace libraries with incompatible ones. Oh yes, you are. > We bring in new libraries, which are incompatible. We keep the old ones, > which are compatible. Our linker knows how to tell which is which. Except that it can't do that if the user happened to use a switch that was available, and its use didn't trigger any blinking light saying that this would cause any future upgrade he might do to silently break his program. If you do want to be able to freely move libraries around, -rpath must be forbidden. If -rpath is available for users, you can't move libraries around and expect things to work. > Who cares where they are stored? The user who used -rpath? > Actually, we do care where they are stored. Ah! And that's where the potential conflict comes from. > My point is, that it doesn't matter if the new library is in the location > the old library used to occupy. It may matter for the user who used -rpath. > Our linker knows which is which. Not always. Or maybe you can fix your linker to do the right thing even if the user inadvertently (incorrectly, in your terms) specified -rpath. > We even support separate versions of software, to some extent, although > I'd agree completely that our support in this area is not what it might > be. And that's the very reason why I've never been able to adopt any of the available packaging systems: the only way to keep multiple working versions is to use a separate directory for each version of each package. >> How does the current packaging system allows me to test one version of >> a package while other users of the same host are running a stable >> version of that tool? Or are the GNU/Linux distributions all moving >> towards the Micro$oft model of single-user workstations? > Of course not ;-) Jeez!, I was sure I had added a smiley after that last sentence. Sorry about that... > If you want to test one version, you simply run it with > ./configure --prefix /home/me/nicepackage But isn't this exactly what the packaging systems are trying to avoid, i.e., that people have to compile systems on their own? And then, how could I make sure that my test build works exactly as the pre-compiled upgrade, so that I could use the packaging system for the update? This is something that I feel that should be taken care of by the existing GNU/Linux distributions. In fact, I've got a bunch of ideas that I'll probably never find time to implement :-( about how to maintain multiple versions of packages installed and allowing each user to select which version he wants to use, either by explicit version number or by tags such as `stable', `test', `old', etc, tags that are determined by the system manager when he installs the package. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil