RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpmio not compiling

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 10 Aug 2011 - 15:12:10 CEST
Message-id: <873805BB-F556-427C-B78B-61A345D6E216@mac.com>

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
Received on Wed Aug 10 15:12:14 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.