Jeff Johnson wrote: >> 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?
I'm not sure that moving from setting preprocessor macros to autoconf variables was needed, both for RPM_VENDOR and these ? i.e. using a --enable-rpmvercmp-digits-beat-alpha versus just setting -DRPMVERCMP_DIGITS_BEAT_ALPHA=1 in CPPFLAGS directly. ... > 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. Right, I actually think the move from vendor to config is a good idea - more uncertain about the cpp vs configure... But obviously the "VENDOR" file isn't used anymore, and the defined(RPM_VENDOR_*) are getting crowded for some. The original idea of moving stuff from downstream vendor patches to upstream conditional code was sound, I think. But it doesn't help with the problem (= different code), it just makes it more obvious when looking at the source. --anders ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List rpm-users@rpm5.org