Closed #128 via ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/128#event-1209931565___
Rpm-maint mailing
@leo-yuriev: libmdbx replacing libdbx may well be the eventual end point.
Deploying a format change as painlessly as possible to end-users is rate
determining to RPM+LMDB* adoption.
I'll attempt a RPM+:MDBX port ifs/when there is any sign of traction in merging
an RPM+LMDB patch, and try to cle
Google Translate works just fine: time to become pluralistic even if you can't
crack a joke in Russian.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/128#issuecomment-318869365
This RFE is implemented in issue #281 and can be closed.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/128#issuecomment-318869381___
Rpm-maint ma
@Conan-Kudo time to learn russian ;)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/128#issuecomment-318854552___
Rpm-maint mailing list
Rpm-maint
@leo-yuriev Would you please translate the documentation into English? It's a
bit hard for me to understand it, as I don't know Russian. :)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/12
@n3npq, be free to ask me for any related improvements in libmdbx.
Additionally, I am glad to boast about new major feature of libdmbx, which is
relevant to rpmdb:
- In comparison with LMDB, nowadays liblmdb provide automatic dynamic sizing
of database file, in both directions - growth and shri
@leo-yuriev: libmdbx looks very nice, but there are several issues that need to
be fixed in an rpmdb schema before attempting better back ends. See other
issues I have reported against RPM ...
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
ht
@Conan-Kudo, please take look to https://github.com/ReOpen/libmdbx/tree/devel
and https://github.com/PositiveTechnologies/libfpta
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/128#issuecom
So, in Fedora, we have a pkgconfig definition for it, which is shared by Arch
Linux and Debian, so this is a non-issue now. It also not being independently
released isn't really a big deal, either, as we do have it as a separate
package that can be used without all of OpenLDAP.
The only remaini
2017-01-26 23:43 GMT+01:00 Per Øyvind Karlsen :
> 2017-01-16 8:04 GMT+01:00 Panu Matilainen :
>
>> On 01/16/2017 02:51 AM, Neal Gompa wrote:
>>
>>> On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius
>>> wrote:
>>>
On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
I'm not sure how t
2017-01-16 8:04 GMT+01:00 Panu Matilainen :
> On 01/16/2017 02:51 AM, Neal Gompa wrote:
>
>> On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius
>> wrote:
>>
>>> On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
>>>
>>> I'm not sure how true it is, but it seems to bear out with the number of
Perhaps @hyc could provide some insight into whether the situation has improved
any since the discussions that occurred in Red Hat Bugzilla.
>From my point of view, the main issues I see are the following:
* LMDB is not independently released (it's part of the OpenLDAP source tree)
* The library
On 01/16/2017 02:51 AM, Neal Gompa wrote:
On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius wrote:
On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
I'm not sure how true it is, but it seems to bear out with the number of
previously BDB users now being LMDB users.
Unless a different DB of
On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius wrote:
> On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
>
>> I'm not sure how true it is, but it seems to bear out with the number of
>> previously BDB users now being LMDB users.
>
>
> Unless a different DB offers substantial advantages over B
LMDB as an alternative to BDB would further help with targetting less-known and
new platforms. and as far as I know, make RPM buildable and usable on midipix
for example.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
At https://bugzilla.redhat.com/show_bug.cgi?id=1086784, there also was kind of
discussion about that.
--
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/issues/128#issuecomment-272
On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
I'm not sure how true it is, but it seems to bear out with the number of
previously BDB users now being LMDB users.
Unless a different DB offers substantial advantages over BDB to RPM,
which does not endanger or destabilize rpm, I do not see
I think most of us are keenly aware that Berkeley DB 5.x is dead. While Oracle
has Berkeley DB 6.x, it is licensed AGPLv3, which seems to make some people
rather skittish.
As a potential alternative, why not use
[LMDB](https://symas.com/products/lightning-memory-mapped-database/)? Projects
lik
19 matches
Mail list logo