dev-lang/python (all versions) with USE=gdbm uses gdbm/ndbm.h in Modules/dbmmodule.c and links to libgdbm_compat. However, in gdbm-1.9.1 and higher, Berkeley db compatibility support is optional, and ndbm.h and libgdbm_compat are installed only when gdbm has the compat USE flag enabled. Therefore, python's gdbm dependency should be changed to something like gdbm? ( || ( <sys-libs/gdbm-1.9 sys-libs/gdbm[compat] ) )
Thanks for the hint - compiling sys-libs/gdbm with USE=compat however results in the following build failure for dev-lang/python-2.7.2-r3 (USE=gdbm) here: "*** WARNING: renaming "dbm" since importing it failed: /usr/lib/libgdbm_compat.so.4: undefined symbol: gdbm_errno" So right now only masking >=sys-libs/gdbm-1.9 will allow compiling python with the dbm module?
@comment 1: no, what you see is bug 383743, that's already fixed in the tree. Actually, this new version seems to introduce a need for a split of the 'gdbm' useflag into two, as gdbm.so doesn't need libgdbm_compat, only dbm.so needs it.
Thanks for the clarification. Sigh - I had considered the "dbm" module as a safe bet, being able to utilize whatever dbm implementation is functional on the system, just to find that dbm requires gdbm compatibility obscure enough for upstream to drop from default, while module gdbm proper works like a charm. And it's the same for dev-lang/python-3.2.2. Probably should go into wishlist for upstream python?
(In reply to comment #2) > @comment 1: no, what you see is bug 383743, that's already fixed in the tree. > > Actually, this new version seems to introduce a need for a split of the 'gdbm' > useflag into two, as gdbm.so doesn't need libgdbm_compat, only dbm.so needs it. Why? I have always interpreted the gdbm USE flag as "use the sys-libs/gdbm backend for storage", and that's exactly what it does here - uses sys-libs/gdbm as the backend for python's dbm module.
@comment 4: no, read the ebuild: use berkdb || use gdbm || disable+=" dbm" use gdbm || disable+=" gdbm" line one needs libgdbm_compat, line two does not.
(In reply to comment #5) I still don't understand why you think a new USE flag is needed. Currently, for the python ebuild, USE=gdbm means "build the gdbm and dbm modules; use sys-libs/gdbm as backend for dbm". Where is the problem with that?
In that now sys-libs/gdbm might not provide libgdbm_compat and it's not required for gdbm module, just for dbm one. There's just something wrong if one useflag covers two (now) independent topics.
Looking at the ebuild a bit more, at the same time we could pull the other possible dependency of dbm module - db - out of berkdb useflag, so that that useflag is only for _bsddb module. It would make for a cleaner distinction of useflag functions.
Do we have a concrete proposal here?
(In reply to comment #6) the problem comes up when we want the gdbm module, but don't care about the dbm module. maybe a new USE flag can address this ? <flag name="ndbm">Build the simple database module (dbm.ndbm)</flag> IUSE="+ndbm" DEPEND=" ndbm? ( || ( gdbm? ( sys-libs/gdbm[berkdb] ) berkdb? ( sys-libs/db ) ) ) gdbm? ( sys-libs/gdbm ) " REQUIRE_USE="ndbm? ( || ( gdbm berkdb ) )" this way we'll only require gdbm[berkdb] when we actually use it, and the gdbm module can be built independently of the (n)dbm module
Looks like this is the last bug blocking gdbm-1.9 tracker, not sure if could be solved finally :/ Should we go with comment #10 suggestion?
Any news? This looks to block https://bugs.gentoo.org/show_bug.cgi?id=518120 currently
(In reply to Pacho Ramos from comment #12) > Any news? This looks to block https://bugs.gentoo.org/show_bug.cgi?id=518120 > currently Well, about the only potential problem I see with comment 10 is that it doesn't implement my comment 8 - given that if by this date bsddb3 module is still alive upstream, there should be an option for not building the out of date copy, even if the user prefers bdb as a backend for ndbm.
[07:39:16] <+Arfrever> pacho2: Bug #383757 bug should not block bug #383747. All dev-lang/python ebuilds currently have "gdbm? ( sys-libs/gdbm[berkdb] )" dependency and all sys-libs/gdbm ebuilds have "berkdb" USE flag. Potential changes in IUSE and *DEPEND of dev-lang/python (e.g. splitting of one USE flag into >=2 USE flags) would not be related to gdbm 1.9 (or any newer version).
bsddb3 is alive upstream. I think that there is no point in building dbm (Python 2) / _dbm (Python 3) extension module against Berkeley DB. (Python 3 has pure-Python dbm.ndbm module, which uses _dbm module.) I would suggest: IUSE="... gdbm ndbm ..." {,R}DEPEND="... gdbm? ( sys-libs/gdbm ) ndbm? ( sys-libs/gdbm[berkdb] ) ..." And no REQUIRED_USE for these USE flags. Building of these modules would be controlled completely independently.
Closing due to no activity. If someone can figure out how this applies today, feel free to open a new bug with clear explanation of what needs to be done.
