Use autoconf to set up some definitions now only available via rpm_vendor_XXXX config
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_
- rpm-lua-
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
- Status:
- Complete
- Approver:
- Jeff Johnson
- Priority:
- Undefined
- Drafter:
- devzero2000
- Direction:
- Approved
- Assignee:
- devzero2000
- Definition:
- Review
- Series goal:
- Accepted for 5.3
- Implementation:
-
Implemented
- Milestone target:
-
5.3.7
- Started by
- devzero2000
- Completed by
- devzero2000
Related branches
Related bugs
Sprints
Whiteboard
Added so far to configure in HEAD and in the branch 5.3, 5.4 :
1) --enable-
and, for rpm.vercmp, by rpm.org
2) permit in configure phase to disable (via --disable-
the optional-
3) permit in configure phase to --enable-
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
complex.
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.
