Any users (such as myself) who have upgraded to openssl-0.9.7 are, as of the last couple days, in big trouble because the openssl ebuild - which was previously for ~x86 and masked (due to 0.9.6 upgrade problems) is now marked exclusively for amd64, meaning portage is trying to downgrade openssl to 0.9.6. The keywords on the ebuild needs to be upgraded to contain ~arch keywords so that those who _have_ taken the plunge to 0.9.7 don't have to fight with portage. There is a comment in the ebuild: #amd64 needs this version or later. So, I wonder: How can "amd64 needs this version" possibly mean "nothing except amd64 should use this version"?
if it was masked portage would have tried to downgrade it anyways ...
I have it unmasked on my system (installed about 3 weeks ago), since the reason for the mask is purely the upgrade issue.
Other distributions have been including openssl 0.9.7 for some time (Slackware 9, for example); Gentoo is behind in this. I certainly understand the issue - I upgraded another system of mine to 0.9.7 a couple months ago, and recompiling the many packages was something of a nuissance. However, there should be a way for _new_ installations to use the _new_ libraries - not be stuck on the old versions of libraries because a clean way can't be found for old systems to be upgraded. This OpenSSL problem is similar to the GCC 3.2 ABI changes - the solution was basically that the system had to be reinstalled, and it was possible to do so in such a way that the < 3.2 systems didn't break. I realize that it is primarily portage introducing the limitation here, so perhaps this should be a portage bug rather than an ebuild one.
If it's simply masked, then adding it to /etc/portage/packages.unmask would let people install it. But as it's only listed for amd64 right now, the only way I know of to get portage to accept it is to create a local ~x86 copy of the 0.9.7b ebuild. However, this won't automatically upgrade past 0.9.7b, unless you also add any newer version to the local tree, and it's kind of a pain to have to go into the portage tree by hand every now and then to see if a new version is out. As for rebuilding packages that depend on this, would revdep-rebuild work, assuming wget had been fetched first?
aliz: any chance of getting this out the door ? we've had the mysql upgrades, the perl upgrades, and the glibc upgrades ... we've got revdep-rebuild in gentoolkit to make this work ... why not put something together ? hell, you could always just include in the 0.9.7 ebuild a symlink that'll have 0.9.6 link to 0.9.7 so they can still run like wget to grab sources to rebuild ...
ok, i know this can easily kill someone who doesnt pay attention to every emerge so ive added dev-libs/openssl-0.9.7b-r1 for people who like to put 'dev-libs/openssl' in /etc/portage/package.unmask
OpenSSL 0.9.7b-r2 commited.
