Use autoconf to set up some definitions now only available via rpm_vendor_XXXX config

Registered by devzero2000

Use autoconf to set up some definitions now only available in rpm_vendor_XXXXX define, set in ./configure.

Currently there are some particular vendor different semantic and implementation in rpm5 code base that it is possible to active only using the configure vendor option.But someone of these definitions could stand alone as enable-feature in autoconf, because they could be useful for other fork of the primary distro (ad Unity for mandriva for example). The first that I think might be useful are:

- file trigger
- branch tag
- parentdir & linkto dependency (it might be useful to disable a first step for porting operating systems that do not use rpm based, such as AIX or openindiana)
- digits_alphas_comparison in rpmEVRcmp
- rpm-lua-extensions-based-on-rpmlib used by OpenPKG today and, for rpm.vercmp, by rpm.org

Maybe some others, to decide. This was the original blueprint.

Thereafter, mostly for the for reasons well described in the relevant analysys section of this Blueprint whiteboard and other discussion, the only feature that i think it is possible to change reasonably in the configure phase, making obsolete the corresponding definitions via the rpm_vendor_XXXX config are those so far implemented, described in this Blueprint whiteboard.

Blueprint information

Jeff Johnson
Series goal:
Accepted for 5.3
Milestone target:
milestone icon 5.3.7
Started by
Completed by

Related branches



Added so far to configure in HEAD and in the branch 5.3, 5.4 :

1) --enable-rpm-lua-extensions-based-on-rpmlib used by OpenPKG today
and, for rpm.vercmp, by rpm.org

2) permit in configure phase to disable (via --disable-dirname-and-symlink-deps)
 the optional-dirname-and-symlink-deps used by Mandriva and Ark today

3) permit in configure phase to --enable-rpmvercmp-digits-beat-alpha for reverting
to the old rpmvercmp behavior where digits beat alpha as used by Mandriva, Fedora,
Suse and other

* Analysis and insights
There are two parts to per-vendor "features": one is through macro configuration
with enablers/disablers, the other is with implementations.

Using AutoFu to change configuration is rather overkill. It simply isn't possible
to please everyone even if explicitly insturmented ./configure switches are added
for every possible "default" configuration. The QA on the AutoFu alone is hugely

On the implementation side, its clear that rpm MUST implement certain features.
What is happening with RPM_VENDOR_FOO compiled in functionality is that
the code is increasingly supporting ancient implementations, with better alternatives
mostly implemented and tested and reliable, largely because of the huge logistical
cost that vendor's face when upgrading RPM.

Its now taking 4-5 years to deploy "features" in RPM. That is way way too long.


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.