Thanks.
As for the stylistic issues:
0 long long is still an integer value, a NULL pointer is a rather special
entity even if the technical value happens to be zero as well. If nothing else,
it's a powerful clue to the user that it's supposed to be a pointer and not an
integer zero, whereas
Merged #980 into master.
--
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/980#event-2943326499___
Rpm-maint mailing list
Updated the pull request:
- about the dbiNew() call that cannot fail: this is copied from the other
backends. I currently left it untouched so that a different commit can clean up
all the backends.
- about using NULL: I think NULL is some leftover from the old K days and
should be avoided.
> I think I'd be more comfortable with this if it conflicted with the regular
> bdb backend option.
Now that I looked this a bit closer, conflicting would be both unnecessary and
plain draconian. If both are enabled in configure, real BDB always wins on
autodetection but either can be manually
pmatilai commented on this pull request.
> @@ -594,6 +594,20 @@ AS_IF([test "$enable_ndb" = yes],[
])
AM_CONDITIONAL([NDB], [test "$enable_ndb" = yes])
+#=
+# Process --enable-bdb-ro
+AC_ARG_ENABLE([bdb-ro], [AS_HELP_STRING([--enable-bdb-ro
(EXPERIMENTAL)],[enable the
pmatilai commented on this pull request.
> + *dbip = dbi;
+return 0;
+}
+
+static int bdbro_Close(dbiIndex dbi, unsigned int flags)
+{
+if (dbi->dbi_db)
+ bdb_close(dbi->dbi_db);
+dbiFree(dbi);
+return 0;
+}
+
+static int bdbro_Verify(dbiIndex dbi, unsigned int flags)
pmatilai commented on this pull request.
> + return EPERM;
+if ((dbi = dbiNew(rdb, rpmtag)) == NULL)
+ return 1;
+path = rstrscat(NULL, dbhome, "/", dbi->dbi_file, NULL);
+rpmlog(RPMLOG_DEBUG, "opening db index %s\n", path);
+dbi->dbi_db = bdb_open(path);
+
pmatilai commented on this pull request.
> +{
+rpmlog(RPMLOG_ERR, "bdb_ro error reading %s database\n", dbi->dbi_file);
+}
+
+static int bdbro_Open(rpmdb rdb, rpmDbiTagVal rpmtag, dbiIndex * dbip, int
flags)
+{
+const char *dbhome = rpmdbHome(rdb);
+dbiIndex dbi = NULL;
+char
pmatilai commented on this pull request.
> + if (meta[4] < 8 || meta[4] > 10) {
+ fprintf(stderr, "unsupported hash version %d\n", meta[4]);
+ bdb_close(db);
+ return 0;
+ }
+ db->maxbucket = meta[18];
+ db->highmask = meta[19];
+
Well, I only said "one possibility", doesn't necessarily mean I think it's the
right one. Technically there's no reason to limit it that way, and like I said,
especially for testing it's highly useful to be able to build both the "real"
and the readonly backends in.
--
You are receiving this
> One possibility to handle the "conflict" might be making it an argument to
> --enable-bdb (eg --enable-bdb=readonly), which then skips the other variants.
> In that case it could technically be called "bdb" and avoid all the
> "configured to blabla, using blabla" warnings from backend
@pmatilai The code works surprisingly well for me (which is terrifying and
awesome in itself), but I think I'd be more comfortable with this if it
conflicted with the regular bdb backend option.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@pmatilai I'm pretty sure I'm going to want this for transitioning OpenMandriva
away from BDB. We're using db6 (even though I didn't want to...), and with the
latest versions of DNF okay with non-BDB, I can finally start considering it...
--
You are receiving this because you are subscribed to
It really is :joy:
Actually the above stats are a bit off, because the Fedora sources include
db-1.85 compat. But the point does hold even with a pristine BDB tarball: it
has 894 *.[ch] source files. And that's missing quite a bit of other stuff, the
tarball has 9241 files in total (including
> In other words, this is fewer lines than the BDB has source files.
This is a wonderful and equally terrifying statistic.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> ```
> 5 files changed, 837 insertions(+)
> ```
>
> :/
To put it into perspective:
```
$ find db-5.3.28 -name "*.[ch]" |wc -l
1037
```
In other words, this is fewer lines than the BDB has *source files*.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Oh my.
I'm not exactly overjoyed about the idea of having custom BDB reader code in
rpm, but given the alternatives, it actually looks almost pretty :grin:
Oh and our database team will love you forever for this.
--
You are receiving this because you are subscribed to this thread.
Reply to
@mlschroe This should probably conflict with the option to enable the normal
bdb backend. I see no reason for both to be enabled at the same time.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ignatenkobrain approved this pull request.
```
5 files changed, 837 insertions(+)
```
:/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
56736fedb0dba9abeaabff829d97c805ba63e0cb Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Added a check for the hash/btree version.
--
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/980#issuecomment-568449448___
Db6 just added support for large data blobs and a heap database type, both are
not used by rpm. I tested it with a cooker container image, and the code could
read the database without problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
@mlschroe I'm going to guess this probably doesn't work with a bdb6-based rpmdb
(e.g. OpenMandriva's rpmdb)?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Updated the code. It's now much faster and also implements prefix search.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
66c055f43b184ab42dc02a219660f866bee48b63 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
97092ae8be7ec0f02c8a4f833f65831625985b84 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
042fdf6d8823ea2b3423134f23217f1d1f96d6e5 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
mlschroe commented on this pull request.
> @@ -594,6 +594,20 @@ AS_IF([test "$enable_ndb" = yes],[
])
AM_CONDITIONAL([NDB], [test "$enable_ndb" = yes])
+#=
+# Process --enable-bdb-ro
+AC_ARG_ENABLE([bdb-ro], [AS_HELP_STRING([--enable-ndb-ro
(EXPERIMENTAL)],[enable the
Conan-Kudo requested changes on this pull request.
I don't know how I feel about this, but...
> @@ -594,6 +594,20 @@ AS_IF([test "$enable_ndb" = yes],[
])
AM_CONDITIONAL([NDB], [test "$enable_ndb" = yes])
+#=
+# Process --enable-bdb-ro
+AC_ARG_ENABLE([bdb-ro],
This commit implements a slow read-only backend that allows
accessing of BerkeleyDB databases without using the BerkeleyDB
library. The code supports btree version 9 and hash version 8
and 9.
There are two use cases for this:
1) Conversion of an existing BerkeleyDB to a different
backend.
2)
30 matches
Mail list logo
