Date: Thu, 23 Sep 1999 01:51:13 +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: <199909222151.BAA05460@tejblum.pp.ru> In-Reply-To: Your message of "Wed, 22 Sep 1999 09:28:41 MDT." <199909221528.JAA13544@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. > > 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 repeat again: this "breakage" is normal and have nothing specific to shared libraries: 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'). Your /bin/test is older than mine. If you install yours on my box, some my shell scripts will no longer work (e.g. the shell script use [ foo -nt bar ]) Your /usr/bin/find is older than mine. If you install yours on my box, several my shell scripts will no longer work (I actually use relatively new "-amin" feature. IIRC, the feature was one of the reasons some of my boxes were run 3.0-current instead of 2.2-stable ;-)). Your /usr/bin/mkdir is older than mine. If you install yours on my box, I will unable to use mkdir from command line (e.g. I have alias mkdir=mkdir -v in my .profile). Etc etc etc. > > > 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'. > This is no different than someone asking if bdin.56.7 is installed. I cannot parse this. What is bdin.56.7? > It > requires some work on the part of the user to get this functionality, Yes, nothing happen automagically. The user is required to install new release, then he will have new features and bugfixes. That's _all_. > and potentially a rebuild of all binaries that it effects. No. I can live without the rebuild. Why you want users to do the unnecessary work? > If you want 'updated' password encryption, you must rebuild all binaries > that use password encryption to be safe. No, I don't rebuild all binaries and still quite safe. If _you_ want to rebuild something, you are free to do so, but don't force me. > However, if we are not adding functionality but are simply fixing a bug, > *then* we don't need to bump the version number. This means that > *nothing* has changed functionally (assuming you can fix the bug w/out > making any external API changes and/or additions), then there is no need > to bump the version. (Ummm. Guess what? In this case, the external API (that is Application Program Interface), didn't have ANY changes and/or additions. (FWIW, it was ever mentioned in my damned commit.)) > > This answer is plain and simple, but break POLA. > > Your answer is no different than mine. Rebuild some libraries, but mine > also requires re-linking the programs that do encryption. And this is the difference. I want the user to do 1 thing. You want him to do, to be very optimistic, 3 things. The difference is 200%. Quite a bit. > > Correct. It may be work, but if you want to run a continually moving > target, you must be prepared to have to do a little bit of work > occassionally. I didn't ever say anything about the continually moving target, FreeBSD-current, in this thread (and other similar threads). I am talking only about RELEASEs. Yes, I am prepared to do a little bit of work. I just want my work to make sense. E.g., I don't want to fix a broken binary _only_ because someone changed a number for _no_ reason. > If you don't want to do the work, then run only the RELEASE candidates. It still doesn't work, because FreeBSD is not and must not be the only vendor for FreeBSD binaries. 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?199909222151.BAA05460>