On Aug 10, 2011, at 6:56 AM, Anders F Björklund wrote: > Jeff Johnson: > >>> 6. Configure RPM: >>> ----------------- >>> # ./configure --prefix=/usr --libdir=/usr/lib64 --with-uuid=/usr/lib64 >>> --with-xar=/usr/lib64 \ >>> --enable-rpm-lua-extensions-based-on-rpmlib >>> --enable-fast-install --enable-shared \ >>> --enable-rpmvercmp-digits-beat-alpha --with-expat=/usr/lib64 >>> --with-neon=/usr/lib64 \ >> >> Hmmm … I did not know there is a --enable-rpmvercmp-digits-beat-alpha >> or a --enable-rpm-lua-extensions-based-on-rpmlib option. >> >> I'm not at all sure what they are supposed to do or who added (its likely >> from RSE and OpenPKG several >> years back). It's sure to be some pretty arcane functionality ... > > Actually it's quite new... > http://rpm5.org/cvs/chngview?cn=15680 optional-dirname-and-symlink-deps > http://rpm5.org/cvs/chngview?cn=15735 > rpm-lua-extensions-based-on-rpm-lib-functionality > http://rpm5.org/cvs/chngview?cn=16017 old-comparision-behaviour > > It came from splitting vendor configuration into autotools configuration: > https://blueprints.launchpad.net/rpm/+spec/rpm-split-vendor-config-in-autofu > > Actual config is the same. > > Not sure it's a good idea. >
Could you be a bit more specific about what isn't a good idea? Per-vendor configuration: an excuse to not work through the best solution. Its always based on a "Not time, we know what we are doing …" mind-set. I don't mind the divergence if "we" did not include "me" doing support and development. AutoFu: I've always believed that compiled in options need to become run-time options. The problem with compiled in options is the assumption that you can re-compile. That is often not the case any more. And its not as simple as adding a macro somewhere when there are deep semantic changes like version comparison, or removing "colors" and not attaching dependencies to files etc: configuration should be about file paths, or verbosity levels, and other UI issues, not fundamental changes to RPM. But somehow per-vendor configuration needs to be merged/dropped imho: blaming RPM (and me) for bugs and lack of support on code that isn't well used/tested, and where "vendor support" isn't an actuality, is, well, not such a good idea. 73 de Jeff ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List rpm-users@rpm5.org
