Opened 4 years ago

Closed 3 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:


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 Changed 4 years ago by Yuri Dario

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.

comment:2 Changed 4 years ago by dmik

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 Changed 3 years ago by dmik

Resolution: duplicate
Status: newclosed

This was actually done within #228 in a nice and fully automatic way that sloves all mentioned problems. Closing this.

Note: See TracTickets for help on using tickets.