Hi Nathanael, Nathanael Nerode schrieb: > Note the following apparent facts: > * libssl0.9.7 and libssl0.9.8, if linked in the same binary, will cause > unpredictable failure due to symbol conflicts. > * This could be fixed if libssl0.9.8 had versioned symbols, which it doesn't > yet. > * I see from pkg-openssl-devel that the plans are to version the symbols in > libssl0.9.8. > > Is this a settled decision yet? (If so, good!)
I think in the Debian openssl team it is settled that we want versioned symbols. I have build a first version and it is working. > Is there an ETA for a > versioned version (ahem) in unstable? I think it can be released in the next days. We want to have some more discussion and testing. And we don't want to make a hasty move and brake other things. > Has it been accepted by upstream. We got no answer from upstream yet. > If > not, will it be done in Debian anyway? I think we will do it anyway. I would only prefere to have it settled with upstream, know how they plan to implement it so that we do not have to change everything if they introduce it. > Will it be done ASAP or are plans to > wait for upstream? We will definitely not wait until upstream releases a version. > If we are planning to wait until upstream accepts this, what will be done to > deal with the problem in the meantime? > > Packages built against the unversioned libssl0.9.8 will, when run on a system > with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 > (wrong) or not find their symbols (segfault). Accordingly, all packages > linked against the current libssl0.9.8 are in trouble and will need rebuilds. > This is not true. I just checked it with versionend and unversioned openssl binary and libraries: unversioned binary with versioned libraries just works fine, no complain, no crash. versioned binary with unversioned libraries results in a warning and also works find. Please see also http://lists.debian.org/debian-devel/2005/10/msg00278.html and followups. > However, currently there is *nothing* preventing yet more packages being > built against it. Are there plans to deal with this? (Perhaps, at the > least, a warning message to d-d-a telling people not to upload packages built > against libssl0.9.8 at this time?) One could do this. > It may also be nontrivial to identify such packages after versioned > libssl0.9.8 goes into the archive (all packages depending on libssl0.9.8 will > require an audit of their symbols to see whether they were built against the > versioned version). This may be avoided by a shlibs bump or package name > change for the versioned libssl0.9.8. A shlibs bump should be done, yes. But I don't want to change the package name. I think it is not necessary. > Finally, are there any plans to alleviate testing migration issues for > packages held up by this, and if so, how? ? Christoph -- ============================================================================ Christoph Martin, EDV der Verwaltung, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED] Telefon: +49-6131-3926337
signature.asc
Description: OpenPGP digital signature