Bug 1788543

What does it mean for existing databases? Do they have to be converted?

Conversion would be the best solution. Because effort is try to remove libdb from Fedora 33. Nowadays I am investigating opportunities of changing databases of dependent packages on libdb. In response I would like to propose some converting utility.
The other choice is change default database to NDBM and holds libdb support in Fedora for backward compatibility until everyone will use NDBM.

We would like to move a step forward by getting rid of libdb. So I would like to ask, which problems do you see with changing backend from BDB to some other database(probably conversion is needed,...)? I want to summarize as much as possible problems with this change across components, so we can find the best possible solution.

The biggest concern is around database conversion and how it will be handled. What's your exact proposal? Change the default database to NDBM? Do you plan on changing it when a new Fedora version is released or in existing versions? In any case, when will the conversion take place? Which team do you think should take charge of the conversion tool?

Finally, IIUC pam is already supporting NDBM. Thus, libdb dependency could be change by gdbm and from the pam point of view everything would be ready. Am i right?

It should be part of new Fedora release of course (Fedora change is needed), which one Fedora isn't clear yet, because it affects a lot of components. New default database should be ideally present in Fedora, which one do you prefer?  The conversion tool should be in charge of our team because some type of conversion is necessary for more components. Now arise questions about conversion, when would be the right place for conversion(during fedora update?)? What about database locations? Are there default paths to databases or it could be changed by users? if so where to find the right locations? Or exists some easier way how to create a new pam database? (My knowledge of pam isn't so good, but some other component can regenerate the database from configuration files and conversion isn't necessary..)

regarding your last question, yes it's our purpose, to change the backend database without impact on users.

Apart from libdb the other option for a database is NDBM so we could stick with it.

As for when would be a good time for conversion, it doesn't have a straightforward answer. There isn't any default place for the database, so it could be anywhere. The only way of knowing where it's located is to parse pam stack files and check if pam_userdb module is used somewhere. If it is, then one of the options must be the location for the database (db=). Thus, when upgrading a search for pam_userdb in /etc/pam.d/ needs to be executed, and either the database is automatically converted or the upgrade fails indicating that the database has to be converted manually. If RHEL9 is going to change the database then the last option would be preferable. As you can see it's not as easy as it seems. Besides, default Fedora and RHEL installations don't use pam_userdb.

I wonder, what is the purpose of `Requires: libdb-convert-util` in:

https://src.fedoraproject.org/rpms/pam/c/557fe26951bab5103a94b7048ba32cb716aecb99?branch=rawhide

Just doing quick search over pam GH repo, I can't see any reference to `db_converter`, which is the only tool provided by the libdb-convert-util package.

`db_converter` is the tool that will convert the pam_userdb database from BerkeleyDB to GDBM. As explained in the Fedora System-Wide Change [1], it needs to be run manually to convert the database. That's why you can't find any reference to it in the PAM repo.

Even if it's run manually, the tool is still needed and that's why I'm adding the dependency.

Links:
[1] https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm

(In reply to Iker Pedrosa from comment #8)
> `db_converter` is the tool that will convert the pam_userdb database from
> BerkeleyDB to GDBM. As explained in the Fedora System-Wide Change [1], it
> needs to be run manually to convert the database. That's why you can't find
> any reference to it in the PAM repo.
> 
> Even if it's run manually, the tool is still needed and that's why I'm
> adding the dependency.

Do I need this tool as a regular user? I don't think so. I don't even know what `pam_userdb` is.

If I needed it, I doubt it would be more then once.

I'm sorry but I can't see the reason for the `Requires`. I don't think that even `Recommends` would be justifiable, but at least it would enable to remove `libdb-convert-util` from the system once not needed.

You are right in that a strong dependency isn't needed. I wonder if it wouldn't be more useful to add Suggests for this case. It's more of a hint, so it doesn't install any dependency but it suggests it.

(In reply to Iker Pedrosa from comment #10)
> You are right in that a strong dependency isn't needed. I wonder if it
> wouldn't be more useful to add Suggests for this case. It's more of a hint,
> so it doesn't install any dependency but it suggests it.

`Suggests` would be about ideal. Unfortunately, I don't think this data are presented to user in any meaningful way :( Maybe it is about a time to open RFE for DNF.

(In reply to Vít Ondruch from comment #11)
> Maybe it is about a time to open RFE for DNF.

https://github.com/rpm-software-management/dnf5/issues/992

I see that issue stalled. Do you agree that the best way forward is to use "Suggests"?

(In reply to Iker Pedrosa from comment #13)
> I see that issue stalled. Do you agree that the best way forward is to use
> "Suggests"?

It is fine for me. I wish DNF provided better support for it ...