Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2021-08-25 Thread Panu Matilainen
As per above, rpm simply does not know enough about the surrounding world to be able to decide when it's safe to automatically convert a database, that will always need an explicit action by something/someone external. The general purpose detection logic improvement in the first commit has been

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2021-08-25 Thread Panu Matilainen
Closed #1012. -- 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/1012#event-5206176687___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-30 Thread ニール・ゴンパ
Hmm, that's fair, and actually pretty much the reverse case of the problem I'm going to have now with openSUSE environments built on Fedora.  -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-30 Thread Panu Matilainen
Yes it only converts in that case, but it'll still wreak havoc in the chroot case where converting might render the chroot unusable from the inside with no warning. That's why I think there always needs to be an explicit request to perform conversion - there's simply no way rpm can know when

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-30 Thread ニール・ゴンパ
@pmatilai My reading of this is that it only attempts a conversion if it can't _write_ in the target database format. So it seems to be narrowly scoped enough to not cause hell, while avoiding the nastiness of trying to do a database conversion on the fly. -- You are receiving this because

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-29 Thread Michael Schroeder
@mlschroe pushed 5 commits. da94ee8195da2bc841e2a4606f2948d46a1109bb Drop useless %{F:..} built-in macro 85e5a70368854da0537099128530b0df69ca2216 Fix regression on v3 package handling on database rebuild d5c69756cf6cd16e7c2e8b81fba19bf81f3dd1ba Explicitly mention that the rpmio/ sub dir is

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-29 Thread Panu Matilainen
Oh and BTW, the code failing with gcc 10 got nuked in commit da94ee8195da2bc841e2a4606f2948d46a1109bb so rebase will get rid of the unrelated CI failure. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-29 Thread Panu Matilainen
The ability to automatically convert is kinda cool, but it's not safe to just go ahead and convert anytime we spot a difference - think of eg chroot manipulation. My plan was always to just leave any database conversion down to an explicit --rebuilddb operation, and maybe add a hint about that

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-27 Thread Michael Schroeder
It fails because of ``` macro.c: In function 'doFoo': macro.c:1211:2: error: 'sprintf' argument 3 may overlap destination object 'buf' [-Werror=restrict] 1211 | sprintf(b, "file%s.file", buf); | ^~ macro.c:1074:11: note: destination object referenced by

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-26 Thread ニール・ゴンパ
@mlschroe Could you please rebase on current master? Perhaps that will fix the failing Semaphore CI run (I don't see anything that obviously indicates why we're getting this failure now...). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-23 Thread Michael Schroeder
There's now a workaround for this. Instead of adding a new dbiSetNextInstance call I've opted to change the put functions to make sure that the next instance counter will be higher than the stored package. For ndb this change is trivial. The sqlite backend doesn't need changing. For lmdb/db3

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-23 Thread Michael Schroeder
@mlschroe pushed 1 commit. de1a21071913b20bbb98a2aadf7991ae8e048304 Implement automatic conversion of the database -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-23 Thread Michael Schroeder
That's also incorrect. It doesn't copy the "next package" counter, so adding new packages will overwrite old ones. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-17 Thread Michael Schroeder
Ok, fixed. I'm not happy about adding a new parameter to rpmdbRebuild(), but it seemed to be the easiest way to fix this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-17 Thread Michael Schroeder
@mlschroe pushed 1 commit. 921b1adf0bcb38ec603be3ffa180794824f80cf5 Implement automatic conversion of the database -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-17 Thread Michael Schroeder
Oh wait, that doesn't work with erases. The rebuildb call must not renumber the packages. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Implement automatic conversion of the database (#1012)

2020-01-16 Thread Michael Schroeder
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1012 -- Commit Summary -- * dbi.c: try the configured backend first * Implement automatic conversion of the database -- File Changes -- M lib/backend/bdb_ro.c (1)