On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote:

>
> Fair enough! It certainly is a difficult balance between avoiding the
> trouble with lusers and still allowing packagers to build RPM with an
> external Berkeley-DB _without_ having to patch the RPM sources.
>

The only patch is the robust mutexes. There's likely a vector in
Berkeley DB that can be overridden, and the POSIX shared mutex
locking can be carried privately within rpm if external db is
absolutely desired. Associating a version of locking with
a version of Berkeley DB at run time to maintain the fiction
of "external" hardly seems worth the effort for what is a rather
trivial "patch".

SO far, I know of no effort by anyone other than myself to
even look at robust mutexes.

> But we can even go one step further: on "--version" or "--help" GNU
> tools often output "Report bugs to <bug-foo@gnu.org>.". We could use
> this with rpm-devel@rpm5.org and in case someone wants to use an  
> option
> like --with-db=external he _FIRST_ has to specifiy something like
> "--with-bugreport=<email-address>" in his packaging or an Autoconf
> error will occur. This way the packager also is _FORCED_ to take  
> action
> (and this way has to know what he is doing) _AND_ the end user is also
> informed explicitly who to contact for support. For instance in  
> OpenPKG
> I would like to use --with-bugreport="openpkg-users@openpkg.org" to  
> make
> sure the OpenPKG users do not directly contact rpm5.org.
>
> Now implemented: http://rpm5.org/cvs/chngview?cn=7567
> I hope this is a reasonable compromise, isn't it?
>

You are more than reasonable. The amount of support pain inflicted
upon me by Berkeley DB has made me twitchy on the subject however. I'll
try to control my tics for a bit, until we can see what types of  
support issues
arise.

There's always engineering issues available if rpm can actually
be distributed and upgraded, a far more important goal.