Custom Query (344 matches)

Many our .spec files take sources right from SVN or GIT via a special block of commands. This code is absolutely identical for each package and just clutters space in each .spec file. It's time to make these blocks simple RPM macros.

Another reason to do that is #228 where we redefine %{version} and %{release} used in our special %setup -n statement, see http://trac.netlabs.org/rpm/ticket/228#comment:5 for details.

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.

This is a long waited feature: automatically download sources whose URL is fully given. In particular, this is useful to build CPAN perl modules (Fedora refers to them by full URL to the source tarball). Other places where it may be useful is libc.spec that depends on archives with binaries which can't be versioned etc.

The resulting macro will go to the os2-rpm-build RPM.