Custom Query (344 matches)

Now, if the %install section of a .spec changes to some dir which is not the top package's build directory (i.e. the directory where %setup unpacks source files to), the %debug_packages macro which generates debuginfo sub-packages, fails like this:

error: Could not open %files file D:/Users/dmik/rpmbuild/BUILD/which-0.0/debugfiles.list: No such file or directory

The attached patches fix this.

This script is to compress man files to gz archives (this significantly saves up space of installed documentation). It used to fail on my machine and I had to fix it (diff attached).

Many dynamic libraries use versioning in DLL names to express incompatible ABI changes (i.e. if the old version is named libxyz1.dll, the new one becomes libxyz2.dll and so on). This way, an old application, built against libxyz1.dll continues to work even when libxyz2.dll gets installed.

Unfortunately, RPM doesn't normally allow two versions of the same package to co-exist even if the names of provided files differ. So the old DLL (regardless of its name) is removed when a newer package is installed. This obviously breaks old applications.

The traditional solution used by RPM-based systems is to provide legacy packages with different names (like libxyz-legacy or libxyxz-compat which include old versions and, due to different package names, may co-exist with the newer packages. However, this approach has its pitfalls:

1. A separate .spec file is required for the legacy version (which requires a separate rpmbuild run etc).
2. If you have more than one legacy version to maintain, you will have to come up with as many separate .spec files and unique package names as you have legacy versions.

This is time consuming and boring, given that all you need from the legacy package is the runtime DLL (which is already built, tested and works).

Another possible approach that is also frequently used is to rebuild all applications involving the given software against the new version and release new RPMs for them. But it is also not ideal:

1. There may be quite a lot of such applications.
2. Some applications may be not ready for the new version and require some work.

So this is also time consuming and boring.

This ticket is to introduce a different solution: automatically create legacy sub-packages within the main package that will take previously built DLLs and just repack them. This requires almost zero work from the package maintainer each time when the library ABI changes in an incompatible way.