Okay okay, maybe not... Add name and path members to backend db_ops struct, use them for configuring and detecting, and misc related tweaks.
Started doing this for implementing rpmdbStat(), but got stuck wondering about the API: my initial version requires an open rpmdb for stat'ing, which limits its usefulness. Perhaps there should be separate calls for an open database and non-open one, just like there's fstat() and stat(). Thoughts? You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/910 -- Commit Summary -- * Add backend name and path of main database file to db_ops struct * Use the new backend struct data for backend configuration and detection * Use paths from db_ops in the backends too where possible * Document dummy backend in macros, warn on dummy fallback -- File Changes -- M lib/backend/db3.c (3) M lib/backend/dbi.c (96) M lib/backend/dbi.h (5) M lib/backend/dummydb.c (3) M lib/backend/lmdb.c (3) M lib/backend/ndb/glue.c (5) M lib/backend/sqlite.c (5) M macros.in (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/910.patch https://github.com/rpm-software-management/rpm/pull/910.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/910
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
