 I did last year a buff on DB Comfort Common, which is a really a DB and native tool. Actually, I got an, for me, extremely good response. It was my first buff to attend at the depth cons while I was giving it. So I really decided to do that again this year. I hope I will be talking a lot less than last year because I want feedback from all of you. But quickly, so what is this talk or this buff about? I quickly go through the important changes that I implemented last year in the DB Comfort Common. I hope that you can share some of the use cases that you see have problems, great stories, bad stories. I'd like to know. And I hope that we can have a look at the database policy. Actually, the person that created DB Comfort Common, Sheenfinery, created a policy on packages that needed database already, well, 12 years ago or so. And I'm wondering if we want to do anything with that document, which is still draft. We could take it up. And actually, I think the question was raised last year if actually packages should be requiring DB Comfort Common in policy in general. So I'd like to have an opinion on that if I should try to take that further. So the last changes since last year, actually, I find the most important one, it took a while to get my head around to properly implement it is the introduction of multiple of other packages that are called after the database type that they're using. And the idea is that packages that only need or only support the MySQL database, for instance, MariaDB database, only need to depend on that package and that will pull in the clients because in the old case, DB Comfort Common had the problem that you as a package maintainer needed to depend or recommend the client yourself, which you would not need in your package, but you would only need it for DB Comfort Common. Now the second great thing I think that a lot of people liked about introducing this is that you as a system administrator now also have a way out of by installing DB Comfort No Thanks to say, I don't want help already by installing the package, you don't get any deep depth of questions. I'll ask questions right away, because it's important. Yes, please. Oh, sorry, just a second. So if you use DB Config, I think it should be green. Okay, if you use DB Config No Thanks, does this apply to all packages on the system that use DB Comfort Common? So there's no way of saying DB Config Common No Thanks for A, but DB Config Common No Thanks for B. Yes, if you want to opt out on some packages, but not on all, you will have to go via configuration, but you can pre-seed that since last year. So that was in last year's talk that you could pre-seed DB Config Common, which was not working very well before. So this is global, the other one, you can still pre-seed, so that should be fixed. Another great improvement I think for most people, so not the advanced user, but most average users is that the local setups, local host setups have improved. So for Postgres, MySQL and MariaDB, as well as SQLite, so actually all the databases that are supported by DB Config Common, on the normal local host, you don't actually need a password. So if DB Config Common can figure out that you don't need it, it will not ask, because lots of bugs were coming in that the administrator just typed in the wrong password because he never set the password for root, for instance. That the questions that get asked have been improved, especially in the error handling area, such to make it more clear what the, in case of an error, what the operator or the administrator should expect from the package, such that you get a better choice. All error handling, you can either say ignore all errors, it will just continue and the package has installed successfully, while obviously it hasn't, but for DPKJ, it just ignores all errors. You can say abort and then actually the installation failed, which is I think the default if you're running in interactive mode and it's ignore is the default if you run in non-interactive mode. Such that you can just continue. The other two options are to try again. Maybe in the background you fix something and retrying is just the right option or the ignore, try again, but ask also all the questions again and then you actually get additional questions and that's made more clear in the templates. Further improvements of course are still welcome, but I also review this with the English and internationalization team, so it should be proper English already, but we can always improve. DB Confircom is written in shell and actually the error handling was relying on set minus E, which means that if an error occurs, the script just builds out. It turns out that there's quite some packages that use the statement if DB Confirgo and then some error handling of its own that kills off set minus E. So the whole error handling in DB Confircom was broken if you did this in your package. So I've requested all packages that do this to not do it anymore, but I also fixed DB Confircom to not fail on that. It just meant that in I think 40, 60, 100 lines I had to add or return dollar question mark, which is extremely stupid, but shell. Apparently some backups can be huge and people don't like them if they're upgrading, so you should now get a question if you want to do that and I extended the auto package test quite a bit. It tests now both low level with all shells that support what I need to support via the policy and as well as I install upgrades, remove birds, things, all that of all the example packages that are included in the DB Confircom. Actually this already caught real bugs in the MySQL upload in Ubuntu, causing them to fix the bug instead of releasing the bug. So that was great for auto testing. So now I really like to hear your ideas, user stories or whatever. I made a, where is it? I'm on Gobi in a that com 16 both DB Confircom and if people like to put stuff there or take notes. So what are things that are going well, are not going well, need to be improved? As already showed on the slide, I have basically two ideas of question of do we need to support more databases? You already said that last year, I have not come around to actually implement it, but MongoDB is on my list. But are there more? Hello, okay. So for supporting the DB, it doesn't have to handle the creation, backups and so on. What I care the most about is that it at least asked me the questions so that I can reuse the internationalized templates of the Conf from DB config. For example, on MongoDB if you just ask what the host name is, then that's enough for me. So do you mean MongoDB is more? It doesn't matter so much to me if you handle creation and deletion and lifecycle management of a database. What really is important is to be able to just ask the questions. But if I would do that, doesn't it make sense? If you do everything, that's even better but it's more urgent to at least have the possibility to ask the questions. Which is very easy to do, right? Well, then the point is that a big part of DB config common doesn't know what database it's asking the question for at that moment. So I would need to check that in the case of MongoDB it's not doing all kind of logic that it normally does. So any other databases that are on request? If not, but if you encounter one, just please let me know. I mean, the bug tracker is open also for wishlist items and I do handle that although I'm about to get there really. Osiko and I already talked so I know his request for the handling of the, what was that DSN thing and I'll look into the script that you already have on that front. Try if I can. You're welcome. Okay, so one of the features I would, I already use myself is that my package needs to read and write a DSN. So it has login password host into that fancy, can you just type a DSN example so that everybody knows what it is? And then, so I wrote the parser in shell script for myself and I'm sure others would use it. So it'd be nice if we could just share it together Oh, that's my software. Okay. So you want to show something of this to me? Yeah, you can search from DBC and there's something. That's a good example. No, no, that's above. Again, above, above. No, it's not at the end of the file. Do you want me to search for it? Okay, so are there other points, success stories that people have with using it or walking into issues with the handling that it actually does? Are your users satisfied with how DB config common handles the stuff? Yeah, so that little bit of shell scripts, I include them on my packages that needs DB config common and it parses the configuration file, ask the question using DB config common, parses the DSN if it already exists, then populates the DBC variables like there, pass DB name type, okay? And then calls DBC go. So that function is to be called in the pre-inst and then there's the equivalent for the post-inst that will write the file. So it does the opposite way. It takes the DBC information from DB config common variables and creates DSN out of it. So in that SQL connection, so you see post-gray, DB user, pass, et cetera. So one of the questions that I actually have with respect to this, I actually at a bug spushing party already a couple of years ago filed a bug against a depth conf where we thought it was a, we created the bug together, where we thought that it would be great if actually we have a configuration file parser that we could just call and that not everybody needs to create his own configuration reading script. Seagull uses any files, but of course there are more. That's actually DB config common has the problem that actually to circumvent the DB depth conf is not a registry issue. It creates an additional configuration file where it stores in its own format the variables that it uses. While it also writes a configuration file for your package with the variables in your requested format, which makes sense for your package and makes sense for DB config common. But in a way we created, although it's a configuration file, it is still a sort of registry in that sense, which I think I will not get around, but I think it would be helpful to actually allow a package way easier to provide DB config common with all the variables out of its own configuration files so that not everybody has to rewrite that own functionality. I think it should not be in DB config common, but if there's no other place, then I think it could be added to DB config common. So what's your idea or opinion on that? I mean, obviously you're trying to get your any file reader out of that. Who here uses DB config common in their packages? Did you raise hand? Just one, two? Okay, would you use these kind of functions? Yeah, maybe, so I don't know. So how do you handle that right now? Do you know? So actually I don't even remember because it's more than a year ago that I did this and it basically was quite a breeze and I'd like to thank you for that, for just integrating these things and I know that I write a configuration file with the specific database information for my package, but I'm not sure I put the information anywhere else, so. No, but still, so the point in DB config common is you need a configuration file in your format. You need one. And we keep a shattered one. If the administrator changes, actually one of the two, that UCF will notice it and will warn the administrator what's going on, but it's still, in that sense, a little bit weird because you may change your configuration file, then you start up DB config common and it will show you not the value that is in your configuration file, but the one that you had during installation if you don't properly tell DB config common. Yeah, it's a bug if this happens. It's a bug in that package, yes. But I think it would be helpful. And actually I think that I also need to check if all parameters are possible. So I think, I wonder, did you ever check that you can change all the variables in your configuration file and see that DB config common is actually using your variable? Have you ever checked that? It does. All of them? I believe it, my script works. Now, if you put something that has absolutely no logic, I'm not sure what's the result. Yeah, so I know by looking at the documentation at least of DB config common, that it says you can pass these variables from DB config common to DB config common at this moment in time. So I'm wondering if there's variables that are stored in your local configuration that could actually get lost this one. So I think I actually should check that very carefully. Okay, so if there's no other remarks on that front, so create a link here. So in DB config common, there's a policy file. Let me check if I can open it. That says, well, a lot of input. Basically what this document describes is what Shin Fenery tried to implement, of course, in DB config common. So at the end, it mentions, well, DB config common is a framework to actually do this. But this tells things about what administrator can expect from packages that handle databases as such as that on how to do the prompting where to install the database about how to handle failure to do stuff that you should allow upgrading and removal. And I wonder if this is useful to pull this further than where it is now. I mean, it's a document in DB config common. It has the status of draft. Should I try or we try to get this into a DB policy or an appendix to that document? I think it would be useful. I'm not a great policy writer, so I'm glad that the document is there, but should I just take it up with the policy team and see what happens if I do that? And what do people think? Should I ask for a packages should use DB config common if there's a database involved? Such that we try to make sure that all the bugs end up in the safe place instead of all over the place of people inventing wheels. Okay, well, I'll try that then. Okay. What I would love to see happening would be a kind of DB helper thing that would make things fully automated. I don't know if I can contribute that. Select, you know, the pre and the dot config, the dot postings and the post RM files. You have to write a bunch of things there with UCF. It's not obvious what to do. And it'd be super cool if users would have nothing to write there and it was fully automated from beginning to start. Back to maintain as you mean. Yeah. And you just do a DH minus, minus with DB config common and then it will do the things. Oh, right. That's a good idea. We're also about one minute in time. So something like that. With space or with equal. Oh, right. Yeah, so the, yeah, I can think of if there's smart defaults that could be chosen there. Yeah, I can think about that. Okay, well, then we'll just leave it here. Always send bugs, wish list items if you have them and find them. Yeah, that makes it just easier to communicate on them and keep track of that. Okay, thank you for your attention.