Opened 9 years ago
Closed 8 years ago
#166 closed task (duplicate)
coexisting packages / legacy packages
| Reported by: | Silvan Scherrer | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | |
| Component: | spec files | Version: | |
| Severity: | medium | Keywords: | |
| Cc: |
Description
We need a way to have different packages of the same port to be installable.
The reason behind it is, when a dll name gets changed, we need to add the old dll somehow still. As other non rpm ports might depend on them. For rpm be just could rebuild all dependent ports and upload the new rpm's. Which is timeconsuming but the right way.
This ticket is to decide how we progress on such situations. Do we coexisting packages or legacy packages. With legacy we might end in several legacy packages for the same port, as every new version might bring a new dll name.
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Well, with pure legacy it's clear more or less and done via -legacy packages in several places already (fontconfig, liftiff etc). But let's imagine a normal project evolution. E.g. currently we have pixman10.dll because libtool version is 0. But the library may become binary incompatible later so that version number will be 1 and the DLL will be named pixman11.dll. Or it may even become pixman20.dll at some stage. How to deal with these cases provided that there may be some other RPMs using the old DLLs that can't be rebuilt for some reason? (e.g. during some huge and time lengthy transition to a new DLL).
Of course, we can gather such DLLs in binary form in the -legacy package but that doesn't look very good because it requires quite a lot of manual work and because we already have packages for these DLLs. We could perhaps modify .spec so that two packages carrying DLLs with different names could be installed simultaneously but this won't always work because besides the DLL itself the package may contain some README that has the same name as in the newer package (where the DLL name is different) so they can't coexist.
I wonder how other platforms solve that. I don't see a nice solution for now. Perhaps we will have to drop this idea completely and just rebuild all dependent RPMs (for non-RPM builds of software we always have ZIPs with all versions so it's not a problem at all).
comment:3 by , 8 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
This was actually done within #228 in a nice and fully automatic way that sloves all mentioned problems. Closing this.
I think a single legacy package is ok. It is already used for libc forwarders. Since dll name changes we don't need multiple packages and sooner or later the legacy will reach its end of life.