Date: Thu, 23 Sep 1999 16:49:08 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: nate@mt.sri.com (Nate Williams) Cc: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/secure/lib/libcrypt Makefile src/lib/libcrypt Makefile Message-ID: <199909231249.QAA02716@tejblum.pp.ru> In-Reply-To: Your message of "Wed, 22 Sep 1999 17:02:44 MDT." <199909222302.RAA16637@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > > > No, you'd rather everyone be confused as to *which* version of > > > > > libcrypt.so.1 is the correct version? With your solution, there could > > > > > be *dozens* of files with the same name that are very different from one > > > > > another, and only the 'latest' version is correct. > > > > > > > > This is normal for every program in the system. You don't have a > > > > version number on cat(1) or login(1). > > > > > > Sure we do. It's called the $FreeBSD$ version number. :) > > > > Good news: the same apply for shared libraries! :-) $FreeBSD$ is not > > the thing we are talking about. > > For people that are running stuff in transition, they have sources. For > people that are running release, they don't necessarily have anything > but what exists as binaries. Bad news: the same apply for binaries, like /usr/bin/cat or /usr/bin/login, as well as to shared libraries. (So, I repeat, shared libraries is no different here than executables). $FreeBSD$ is not the thing we are talking about. > > > > This is normal for shared libraries as well. Version number on a > > > > shared library is only a something about binary compatibility, it has > > > > nothing to do with the feature set or somesuch. > > > > > > You got it. My libc.so.1 is *NOT* binary compatible with yours, because > > > yours is newer than mine. Therefore, if I install mine on your box, > > > then programs that previously worked will no longer work. > > > > I repeat again: this "breakage" is normal and have nothing specific to shared > > libraries: > > No it isn't. If you believe this then you are mis-informed. Arguments? You are wrong. If you believe otherwise, you are mis-informed. > > Your /bin/sh is older than mine. If you install yours on my box, some > > my shell script will no longer work (e.g. my shell script use new > > 'read -r'). > > Then your shell script isn't portable. But, you never claimed for it to > be portable, so you wouldn't ask me to run it on my box. Perhaps, my script isn't portable, even though 'read -r' is in the standards. So what? Maybe you think that every program you run is portable? You are mis-informed then. I only claimed that my script will work on FreeBSD 3.2-STABLE as of 1999/09/02 and later. I added a new function to libc.so.3. You installed your older libc.so.3 on my box. The programs that broke are not portable -- they use my new function. > And your point is? And my point, as I said, this: When you add new feature to sh(1), you don't start to call the binary /bin/sh.17. Nobody want to hear "/bin/sh.17 and above can handle 'read -r', but /bin/sh.16 and below cannot do it". You don't regenerate or edit all shell scripts when you upgrade to new version of FreeBSD, to put correct '#!/bin/sh.17' in them. Likewise, when you add new function to libc, you don't change its name, aka "version number". > > Sorry, I shortened the actual question of the imaginary user. The full > > question is like this: "I was running FreeBSD 3.3-RELEASE. I just > > upgraded it to FreeBSD 4.1-RELEASE: I fetched new sources via cvsup, did > > 'make world' and installed new kernel. Can I use SHA1-encrypted passwords > > in my password database, now?". Again, my answer is: "Yes". Your answer is > > different, because the user didn't upgrade the binaries that was not > > installed by 'make world'. > > If you upgraded to 4.1-RELEASE, you will have *all* sorts of problems > with older binaries. Really? Why you think so? I have tried to run 'older' binaries on FreeBSD-current (FreeBSD-current is currently a version of FreeBSD similar to 4.0-RELEASE). They works _fine_. > You may also have problems with utmp sizes from > old binaries. Please return back to reality. utmp sizes did not changed after 3.0-RELEASE. That incompatibility is long in the past. Well, I will not be surprised if I will have few problems with old binaries. Just because nothing can be ideal. But "*all* sorts of problems" and "few problems" are very different things. > Making you and others who want to stay on the bleeding edge 'pay' a > little bit is worth the pain and suffering that others who don't want to > bleeding edge don't have to pay. I agree :-). Hear, hear. This is my goal. See above and my previous mails. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909231249.QAA02716>