Joe Morris wrote:
I believe his warning isn't so much just the need to rebuild openssh, it is that there are many OTHER packages that are built against the libraries in openssh, which all may need to be rebuilt against the newer version of openssh. It can be a dependency nightmare of sorts. ..... I think you are missing how many other programs use openssh and link against its libraries. Changing it may mean rebuilding a lot of other programs, which may rebuild with the newer openssh, or may introduce problems related to a newer version.
---- If I was installing the 11.0 "binary" packages, I'd agree that I might have problems -- especially if package requirements have specific versions of libraries that are needed -- but USUALLY, third party packages that are build from "tarballs" using "Configure" and 'automake' are designed to build against the libraries on your system. It is almost never the case that packages build against specific versions of files. The most likely dependency is against another "package". The next most likely is one that says the package must be >= to some minimum version. Unless there have been major feature changes in a product, most don't require upgrading packages.
Am not sure why you would be pushing customers away from building their own versions of packages that they need for their systems. Isn't that one of the main 'selling points' of Open Source?
This is true, but replacing a brick at the foundation is a lot more different than one at the top.
This one is a matter of perspective. openssh, in my view is a brick at the top of the wall. I'm not replacing *underlying* libraries. It's the "top-most" application -- it doesn't provide libraries for other applications -- it provides command line utils (and a server). That command line interface is pretty *stable*... But I'm aware of dealing with the low-level bricks -- I regularly build my on kernel from the vanilla sources and configure them for my machines -- if that isn't replacing one of the "low level bricks..." :-)... Lots of software in "user-space" depends on functionality in the kernel -- there are multiple features in SuSE's standard kernel that aren't in the vanilla kernel. Utilities, and startup scripts above the kernel that assume they are running on a SuSE kernel need to be "addressed". While it isn't a "slam-dunk", I figure that if I can replace the bottom-most bricks (like the kernel), I should have some possibility of successfully dealing with a top-level application like openssh...:-) But I never know until I try...:-) Software gets more complex and twisted all the time, so there may come a day...*sniff*...*I'll cry & whine*...:-) But *if it is important to me*, I'll get back up and try to figure out why what broke, broke. :-)
I can only guess at what CR was implying, but I believe I understood him correctly. It isn't that it cannot be done, but openssh, openssl, etc. are used in a lot of other packages. I have attempted similar things in the past and can understand what he is warning about, i.e. you want a newer >, but 10 package need xxx.so.1, but the newer has xxx.so.2
This is a very rare case if you are building from source -- though it is *very* true if you try to install binary packages from different revisions -- but unless the new program (binary or source) relies on new library calls that didn't exist before, specific version dependencies are usually "invalid".
all 10 packages now need to be rebuilt,
Have never had a source package require packages to be rebuilt -- I know it's possible, but in 10 years of linux development, I've never needed to. Most 3rd-party packages use "configure" or something similar -- which checks the machine you are on and builds the product to your machine -- never to specific file versions (product versions may have minimums, but files versions are (I hate to use this word...but...) never required in 3rd party packages -- because they are designed to build on multiple platforms where file-versions are often to be completely different. but even after rebuilding
(assuming they all rebuild), there is strangeness that wasn't there previously, and now you need to figure out if it is the relation between one of the 10 to the new library, or the new library itself, etc. It isn't trivial. It can be done, but it takes work, and thus his warning. HTH.
The warning is not that applicable to source rebuilding. There is *some* validity -- like the new openssh -- IF compiled with the krb-gssapi option, makes some "new" call, but the easy work-around there was to not include krb-gssapi in my build -- I don't use it. Problem solved. In fact -- that's been the most common type of conflict in bringing later-versioned rpm-src packages into an earlier version -- teh newer version uses some software or hardware feature that I'm not using, don't have and usually don't want. So, I remove the *added* complexity and the resulting software is usually more reliable, smaller and faster. Those are all good benefits that offset hassles of identifying and removing new "requirements" (which are, _more often than not_, "bogus"). Like gssapi -- that was a government led protocol that has since been deprecated (security problems with the protocol). So not only do I not need it for my systems, but I really wouldn't want it. It 'should' be, IMO, deprecated in SuSE as well if not just 'removed'...but there could be some customer...so whatever... Thanks for the concern and feed back though.... Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org