|
Bugzilla – Full Text Bug Listing |
| Summary: | libopenssl1_0_0 conflicts with libopenssl0_9_8 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Michal Marek <mmarek> |
| Component: | Basesystem | Assignee: | Guan Jun He <gjhe> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
does 'rpm -Uvh' working? That's not the point. I need both packages installed, which is not possible if they both install into same paths. version 1.0 is a upgrade,not a completely different package.So,maybe that's not reasonable. The whole point of the shared library packaging policy (http://en.opensuse.org/Packaging/Shared_Libraries) is to be able to install multiple abi versions of the library (to be able to run applications linked against an older version). In particular, the openssl packaging violates http://en.opensuse.org/Packaging/Shared_Libraries#Exceptions, point 3: (3) If a shared library package lib$NAME$NUM must contain other files than shared libraries for whatever (approved!) reason, their names must be made unambiguous by putting them in a versioned directory or by versioning their names to not conflict with the rationale of this policy. ok submitted. The openssl package in Base:System is completely broken now :(. Please do not move /usr/lib64/libcrypto.so.1.0.0 and /usr/lib64/libssl.so.1.0.0 around, otherwise programs linked against openssl will not find them. Also, we probably don't need a devel package with versioned paths (and the *.pc files have fixed paths anyway). (In reply to comment #7) > The openssl package in Base:System is completely broken now :(. Please do not > move /usr/lib64/libcrypto.so.1.0.0 and /usr/lib64/libssl.so.1.0.0 around, > otherwise programs linked against openssl will not find them. Also, we probably > don't need a devel package with versioned paths (and the *.pc files have fixed > paths anyway). I can solve this.but,I want to know,why do you need libopenssl1.0.0 and libopenssl0.9.8 co-existing?if you are linking program,just use libopenssl1.0.0.I can not find the value to get it in version directory. For instance the acrobat reader is linked against 0.9.8 and I can't rebuild it for obvious reasons. OpenSSL is a widely used library and the 0.9.8 version has been there for several years, so we can't just say go upgrade all your programs to 1.0.0. openSuSE11.3 even not provide libopenssl0.9.8-devel(just libopenssl0.9.8),so if you want to develop with openssl(comoile,link),it's better to use libopenssl1.0.0-devel. I'm not talking about development, but about compatibility with existing programs. ok,anout compatibility with existing programs,I just submitted an updated to Base:Syatem,and you can try it. best, Guanjun I sent you a submit request (39113). already existing programs linked against libopenssl098 may call the engines,in the 'engines' dir,so,it is needed to keep the old engines dir,and that conflicts with verison 1.0.0s.so,we need to keep the co-existing of libopenssl0_9_8 and libopenssl1_0_0, and only provide libopenssl1_0_0-devel for new developping programs.if change libopenssl1_0_0 to find engines in a versioned dir,it's better to submit it to upstream first,other wise,there are many potential maintence issuses. already fixed. close it. |
The two packages cannot be installed in parallel, which defeats the purpose of the shared library packaging policy: # rpm -ivh libopenssl1_0_0.rpm Preparing... ########################################### [100%] file /usr/lib64/engines/lib4758cca.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libaep.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libatalla.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libcapi.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libchil.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libcswift.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libgmp.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libnuron.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libsureware.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 file /usr/lib64/engines/libubsec.so from install of libopenssl1_0_0-1.0.0-1.2.x86_64 conflicts with file from package libopenssl0_9_8-0.9.8k-8.2.x86_64 Is it possible to use versioned paths here, like /usr/lib64/openssl-1.0.0/engines/ ?