Date: Wed, 22 Sep 1999 17:02:44 -0600 From: Nate Williams <nate@mt.sri.com> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: nate@mt.sri.com (Nate Williams), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/secure/lib/libcrypt Makefile src/lib/libcrypt Makefile Message-ID: <199909222302.RAA16637@mt.sri.com> In-Reply-To: <199909222151.BAA05460@tejblum.pp.ru> References: <199909221528.JAA13544@mt.sri.com> <199909222151.BAA05460@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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. > > > 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. > > (Umm, you are apparently talking about Solaris - this is the second > nonexisting .so.1 library that you mention? Please switch back to FreeBSD > :-). I'm using the numbering as an example. Maybe I should have said libfoo.so.1. ;) > 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. > 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. > Etc etc etc. And your point is? Your /bin/sh won't even run on my box, since it's too old to run ELF binaries. :) > > > > That portion of your commit was wrong, in that it violates POLA. Yes, > > > > it's more work for you, but that's the price *YOU* pay for tracking a > > > > system that is in constant development. > > > > > > Oh. Note: there is only one password database in your machine. An user > > > ask the question: "Can I use SHA1-encrypted passwords in the password > > > database?" My answer (it is also in docs): "Yes you can." > > > > So far we're in agreement. But, my answer would be different than > > yours. My answer would be to upgrade to FreeBSD-X.X for sometime after > > month-day, and do a buildworld to get the new functionality. > > 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. You may also have problems with utmp sizes from old binaries. It a problem you must face, and sacrificing forward compatability and the nightmare the ensues with this is simply not worth. In short, the benefit of re-using the major number of the library is not worth the nightmare that ensues. This can be proven by watching the Linux users flail around trying to find correct shared libraries. 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. Nate 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?199909222302.RAA16637>