 So, yes, we're starting. So, for that sort of nominee, I'm Florian Festi. I'm one of the RPM developers. And I set up this workshop to collect a bit of user feedback on basically what we are going to do in the next big round of features. We are going to start after the discussion with Jean Lapidin. So, while we are doing this, the issue that has always plagued RPM is that RPM developers are not ready for this workshop. I mean, we do have packages, we do update and stuff, but we're not really maintaining a huge set of packages. So, there's always this cute view on the RPM world from the packages. And it's more of a problem, sometimes less of a problem, but even the features we implemented like the last couple of years are at least in my mind, maybe Pano is a bit different on this, but it's basically from the perspective of a user like basically from the installation process. So, well, there's all those scripts that are running and they are confusing and complicated, and we don't like this, so we add file triggers. But it's not actually, at least in my mind, not from a package perspective. Yes, it simplifies packaging a lot, and of course, consideration is not like an accident, it simplifies packaging. It's not been like the main focus on many stuff we do. And obviously, that's a problem. And so, I thought, well, if I'm in Flock, we can basically take the opportunity to get us some feedback and to get access to maybe stuff that we are missing. Maybe as a prerequisite so that the interaction between RPM upstream and Fedora has always been an interesting one. So, obviously, RPM is a very redhead project. We have two and a half people working on RPM, and Fedora is basically, from our point of view, the purpose of Fedora is being a testbed for the next RPM release, maybe among some other minor things, but that's the main purpose of Fedora from our perspective. And so, there's this weird interaction. For one, we are implementing something new and we have to feel like we should push it into Fedora. On the other hand, we are not really proud of Fedora. And so, I always had a feeling that Fedora needs to have its own opinion on what it actually wants from its packaging system. It's not like our job to tell Fedora how packages should look like. But on the other hand, of course, we do. I mean, if we implement a new feature, that's what you get. It's not like you can choose. You can choose not to use it, which still makes me unhappy. I'm not looking at anything specific here, except maybe the tiller version compare. But, so it's always been interesting. And what makes it even more complicated is that RPM, of course, is also the packaging system for a lot of other distributions. So it's very important for us not to look like we are in redhead of a Fedora-centered project. So we've been working very hard on this the last couple of years. I don't know what's long enough with this to know how things looked like ten years ago, where the communication with upstream was not always as it is today. But we've come a long way to present ourselves as an upstream that's independent and open from input from all other distributions. That's something we stress a lot, and it's very important to have the trust of all the other distributions. And it has actually paid off with many other distributions coming back to our line of development. So we're very happy with that. But still Fedora is something special, and so I'm hoping for more input from that. The thing I have a suspicion about but I don't really know and I want to find out today is I think that the packaging problem in general is not that interesting. I think the interesting thing is in my mind is there's like islands of packages that have special needs and do special things that are probably worth looking into. Probably based on the languages that are implemented in these packages. I hear there's a big... I had a lot of work to get Python from the Python 2 being the default to switch it over to Python 3. And my guess is there are a lot of other issues like that that are very time-consuming and have special problems that probably or maybe need some support from RPM or at least maybe supported better than we are doing today. That's what I want to find out. So I hope you all have your small pile of packages that you can basically tell a story of what that package is about and what problems they run into. So this is being a workshop and the idea is that you work for our ideas and if you're all happy with how RPM works and your packages are just fine it will be done in like five minutes which is also nice. If not, we will take a break for coffee and then we can continue for a second hour depending on how this goes. I have actually no idea about this. So maybe a few remarks on features in RPM in general and that may be good to get a discussion started. There are a couple of things that makes it difficult to add new features to RPM because they are opposing forces dragging into different directions. One of those is everyone has this small little feature they want to have to get rid of these one line or two lines in this one package that's really, really annoying but we won't and I can tell you why because every feature we add adds burden to all the packages who need to know about it who need to look it up if they encounter it. So having many small features that help with small things adding costs that we would rather write to avoid I mean, we already have too many features to be honest. Packaging is already so complicated there are so many things you have to know about and on top of that you have packaging guidelines that don't only tell you what features there are but how to use them, how to use them properly which not to use, which not to use in a special way sounds too complicated already and we added a lot of features in the last year so I'm hesitant to add small features unless there's a really good use case for it like either things that cannot be solved properly or that actually have an impact that outsets the additional weight which for example file triggers clearly do we have been able to shrink the size of all the spec files a lot with them and it justifies the additional feature even if it's a bit complicated in its nature then there's another very interesting thing that I'm thinking about this is where to put the control over what's happening and there's basically three places that are fighting over or struggling over control what's happening that's for one of course a PM upstream which does stuff and that basically creates law on how things happens and has the force of C code implementation behind it then there's the distribution which is currently in my estimation the weakest part because they are mainly down to policy and good will of the package and then there's the packages who are able to do things and what makes it complicated is that there's justification to push the control out to the details but on the other hand you add the burden of things being non-uniform and complicated and repeated all over the place so to maintain something that can be worked with it's important to basically pull back the control and centralize things and cannot create policies to unify and make things more uniform than they are and that's something I'm currently not too happy with in a way that a lot of things are done in the distributions but are not shared between distributions where RPM is not like gaining control by a lot of force and it's something I would that's probably not that much for this discussion but in the long run I would have the distribution coming together closer and having share more of the things like macro files and dependency generators and basically rules how packages are done because this has run away quite a bit we have pulled it together to some extent but it's of course an ongoing struggle to keep that back there was one rather poignant us back to this later so that's basically my introduction so I would start with basically collecting use cases and packages and so maybe start with who I'm talking to who is not maintaining any packages okay, it's okay who is what happened to that guy so who is maintaining 5 for less you probably 5 for less 10 for less 20 for less 50 for less 100 for less more than 100 okay so we have the whole set of involvement so who has a set of packages he wants to showcase so the question is are there sets of packages that are special in some way and it may be interesting to look at for additional support to make them packaging easier that's the main theme of the day anyone the Golang packages that you have the Golang, okay so what's the problem with that what's the challenge so right now if a Golang package has a lot of models you have to do each and every thing even if you have the under direct so then how if you already have the under direct then why we have to add each and every thing you can have separately in the package also so you basically duplicate them a lot of so there is an automatic generated package for the Golang packages that's actually basically whatever it's clear to all the source files of the Golang and actually look each and every model as part of the spec file which is already part of the under direct so it has a spec calendar and it duplicates all the information that we already have yes so it has it has all the model information which are already part of one of the direct and usually for doing the very process so is this something that actually puts broader on the package or is it just annoying so it's automated basically it duplicates general problem not only for Golang we have multiple tools to generate spec files for example Python who need maybe Rust and there is a lot of things that is automatically generated when you add the package to the distribution and then when you update it you either generate it again for the new version and then compare it or you just update the version and hope for the best and then if it doesn't build you out the missing build require but you sometimes forgot to remove the obsolete one and like having a way to either have automatic virus which is something that I think there is an issue for it on GitHub or even more having something to generate the spec file as a thing that we don't maintain anymore that would be also great so it's basically a build system issue so basically we have a lot of software that would generate an RPM spec file basically but we are assuming they are edited by hand basically and then the problem is basically to integrate this into the build service or the build system and the build workflow so so the question I have is of course obviously cannot do anything about the workflow which is outside of RPM wondering if the problem is we actually do manual work with RPM of course like doing updates, backporting patches so how does this work here so this is a mixed workflow so you rerun this if you update, if you do a rebase but you do also manual work on this or is this basically good actually just automatically I'm asking I would say that currently it's not 100% automated the question is could it be automated or do you actually have to still like put patches in it could be automated if there is a way you say okay make the upstream method data generate the spec file back directly and this is what I add for it like a batch for the spec file or additional data or additional steps so if you had a perfect upstream it could be automated so we could get upstreams and patches we want the patches because that's basically what RPM from the build side is about it's basically about putting patches on top of something else and then build it build it and stuff we do a few other things but the main design thing from the spec file thing is having the tile ball and then doing some patches which are separate and extra so the trick here would be basically find a way to put in the patches and probably the change log associated with them on and insert that back into a re-generated spec file need something to do on another idea stack over loads question like ok I done pip install full get install full why RPM doesn't know about my library I said of course do answer is obvious but the question is why we couldn't do something like RPM dash dash I forcefully to think big something like this so I let manually insert python parenthesis something and the parenthesis so why not I think you just thought you would probably need your root for that so one of the problems of course that all those installers are basically run as a user which is a tricky thing for RPM especially if you how we can start the root install this so I'm just reading dummy cf file I will just run some command RPM database ideally with some tag that ok this doesn't come from any RPM I was installed using 5 or gem or some technically probably isn't that difficult I think we have not done it because it's basically a bit of out of scope for RPM so the question is for stuff like this the question who is actually doing that so that's also something that that's an interesting problem for RPM right now the question is what actually is RPM what is actually part of the different languages surrounding it so we still have a lot of dependency generators in RPM package itself the question is do they really belong there or do you actually want them would have like the python dependency generator part of python or part of something in between well the use case is that I have some application which requires python-full but for some other application I need python-full to be most recent one why the first application requires any obviously use case for modularity but let's step aside from that so when you install python-full from upstream then RPM doesn't know about it so the first application doesn't have the entry in RPM database so you are somehow stuck and say why doesn't work that's the usual question on this problem basically as far as I understand they make RPM somehow aware of the non-RPM install files from wherever and I know some sort of make integration from the language-specific package manager like package managers like I think which would be of course something that's burning for our stream and so on but I really think it would be useful from the user perspective because us packages already know that you're not supposed to install packages or things with language-specific package managers they do not play very well in the system so how RPM was able to come in from the repositories or anything it's part of the installation from our language-specific package manager it would make things a lot easier and it would promote creation of various tools also around it so yeah I think that might be a very long scope but it's definitely a very easy case that applies to many people way many people at this time well they're just quite as similar in a different context and the question was if you could actually force our PM to actually look on the disk what's there and it's currently not done traditionally to like enforce people to not install stuff otherwise and there's of course an argument to be made that's kind of the right thing but maybe not but at least people trying to sort of run script to figure out what is not owned by RPM to find out what has been installed in the system but every on the internet you are a new developer and you will find instructions on how to use language-specific so you just have to keep loading up their system to do that did you want to do slides? no okay because I brought a dongle no we're fine so we're getting there are a couple of things that can be done so the reason we've not done it is because it's a weird space in between RPM and the tools and whatever but I understand that's an issue and we will probably try to figure out the results with that one more thing which is probably really unrelated so with keep we can during sub pages of our husband we would have some patterns for example if there is some something like a user I can run to seven side pages then generate pattern to full sub pages with some special provides so basically after that we would just each RPM or any other tool just to read file system, find those files which are not owned by any packages and then just run those generators and this is very good so basically you have package patterns you have to create your own package tool for this but if you add some patterns or libraries or development parts you can do it also in your time and basically so maybe I'll repeat that so the idea was basically to have patterns that from files on disk that would be turned into packages that can be installed to basically tell the RPM database well you have these Python packages installed from different sources and stuff like this this would have the benefit of not relying too much on the package format of the libraries of the languages but we could basically just say well these are the locations we are interested in if we encounter some of them we will just pick them up and tell the database but the problem with that if you update one of those packages using some other system than DNF everything will break because it depends on the older version yeah well the problem with this is I mean that's generally the problem if you have like multiple sources for packages that are not managed in a centralized way that is basically you get outdated I mean if you install and then delete it from a disk it's gone and no one knows about it I mean yeah if you just delete it from a disk and you install it with RPM it's also just gone but no one does that and if you do it yeah but we don't care about those people but it's more likely to happen if you have like a secondary tool that actually does that and updates it and replaces it with a background of course it's proper dangerously trying to install and make it on the improved work ground and embrace the color of the line I'm a bit afraid of that yeah you should be we all should be but the thing is what's the proper use of something like this if you have a production machine and you do something like this yeah you probably deserve help and you will find yourself in there quite quickly if your problem is that the customer doesn't really already know yeah that's the problem but I mean for a developer that basically just sets up his small project and says well it was the fastest way of getting it that way they just boost the stack overflow it doesn't really solve any it doesn't really solve any if they already know how they should do it they're fine it just install at the end if it's available it's available or make a virtual environment or just do it the proper way I mean to solve this properly would basically mean hacking into those packaging systems and basically synchronize from there to the database I think you can solve it by creating the RPM based on the upstream format and then installing it at RPM and calling that to pip or channel or whatever that way if RPM is feature wise a superset of all the other ones that could be possible but I don't really see a way to hack around an update problem by mixing the repository by mixing the package database if you want this to really work lively you have to do it properly that's the story of RPM unfortunately if any of those language specific install mechanisms have any sort of centralized database for tracking what it is put in because most of these tools also want you to use that tool to take it out and not to have you go randomly deleting files on the process I think it's far more likely that a user who is done with a component like that is going to do the tool that they use to take it out again I'm not speaking in specifics here but if that tooling has a database that says this is what I have put in on the system it would be very valuable if RPM could directly query that database in a standardized language in a way so that if a user used that tool to install something that RPM can at least expose that information of what that other database says it has we have to trust it to a certain extent because that other tool is trusting that so one problem with that RPM is actually really nice Python's pip doesn't have a depth solver so if you take something you break your system and again it's not going to work for every single one of those systems it's going to have to be looking at those ecosystems and saying which of these are built sanely in a way where we can answer to these questions some of them probably are I haven't spent a lot of time carrying them apart trying to glue them into RPM but I would wager based on what I've seen from Go that there's possibility of being able to pull from its transaction history and being able to do reasonable data generation back so we can see what Go files are littered all over the place Well, we said that it doesn't have any solver so it's the way that right now we couldn't do anything about it so again we will provide you a gun and it's up to you to shoot your tool or you are you know what you are doing so if we do something and if you know what you are doing you can do something if you don't know you should do yourself into lack or into the body well that's the problem we are trying to solve here just back over to questions from people who don't and I wouldn't have shot themselves in the foot if that's not a problem then we're done clearly the problem is that we can't possibly package everything and thus how do we how do we have the stereo ecosystems that are mixing how do we minimize the pain for people in these ecosystems understanding that we cannot necessarily change the PIP ecosystem we can certainly suggest changes and they can tell us to go pound sand but what can we do on the RPM side to minimize the pain that a user or a developer will feel I mean the question also is even if people have like PIP installed something and say well RPM doesn't find it and my other stuff doesn't install basically having a way of reinstalling this properly through an RPM build thing on the right place on disk is probably a good enough solution to actually not use the one thing they put somewhere in their home directly but to say well I mean the problem is even if they ask a question you can say well just do DNF install something but it's not helping if the stuff is not available I mean that's if it were all available as a package it wouldn't be a big deal to say well you didn't PIP install just typing again with another prefix don't do it with sudo all the notorious ads you can buy them books which actually suggest that you install something but the actually problem is that telling people just use DNF won't help them because most of the stuff is actually not a package so we need a solution that actually will put everything basically that's available on PIP on the disk somehow in the same way I don't think trying to solve this from the RPM side the problem is a good solution so there isn't for PIP because that's all I know I don't know how other things work there is an upstream issue that if we install stuff in RPM packages and mark it as installed by RPM which is there is a way there is an installer file that could say PIP or DNF or RPM or whatever PIP could behave in a way that if the user tries to upgrade a package then it was not installed by PIP but by some distribution package management the PIP would refuse to install it and then it could tell you you don't do this instead do something else and the something else doesn't necessarily mean do DNF install because we know we can't package everything it could tell you use a virtual environment or use Dish-Dish user to install it to your home directory or whatever and I think this is a better solution for PIP than to try to hack around it on the RPM side on the other hand it means we need to solve it for PIP then we need to solve it for RubyGems then we need to solve it for CTAN then we need to solve it for whatever else is there and it's a lot of work and each of these ecosystems and installers is different and the fix would work in a very different way but trying to comprehend this from the RPM side like guessing oh this looks like a PIP installed package because of this then do something different that's kind of hackish I agree and that's probably the reason why I've not really looked into it because the proper solution is probably coming from all those different domains that need to offer a solution on their own but such as CTAN we can have something like Federa PIP you will call PIP to install something and then we'll put something into RPM for example so RPM will just have to put something into RPM so at least you don't need to provide it for the RPM command you just need to provide something in RPM lead so I can call RPM lead and say okay I somehow install PIP putting something into RPM lead of your market installed by external application and everything will be done in those applications and not RPM we just provide the problem currently is there's just basically a matrix of problems you have the different languages on the one hand on the other hand you have different languages on the distribution side also it's not like we have to tell the Python people well do this for RPM and everything is good no no there's the deviant people coming and who else who will basically come up with the same demands so I think there's still some untangling to do to actually probably basically have an interface in the middle where you can basically merge both sides onto each other having the full complexity of it I would probably want to stop this discussion here and look for other packages because I mean it's a very interesting thing and we saw I don't know one of our horrors and we can pick it up later on but I would rather have more looks into different packages in Fedora actually just something before about the Python packages basically or do you want ask the least whatever you want the main package, the main question I have is what do we need to do to make the Python 3 to Python 4 transition more easy there's a very simple answer to this never do Python 4 that's not my question also modules should really help with this but I don't I don't think you need to do stuff on the RPM level if modules are ready at that time which depends on the date yeah even the ones we don't have I'm just trying to define what have you seen maybe from our side because the package is on the transition like is it the sub-package issue or anything like that I actually don't know why I'm asking you okay so what I don't like is that RPM upstream makes a lot of assumptions about Python itself like there is user from Python that says D Python and this is the only Python everything should use and then you can use X to work around this one example is the auto-magic relation thing there are everything that happens to be called .py is byte compiled by user from Python which is completely various assumption and then if you need to paint this on the distro level there is no clear way where would we do this because there is RPM upstream then there are patches in the RPM package of RPM in Fedora and then there is redhead RPM config and then you somehow have to squeeze all these three things and something comes out of it and then RPM upstream changes something a little bit and then it's defined in two different ways and again it's not working so the main problem is that RPM and this is maybe a good thing generally or bad I don't know is trying to do stuff that I think the distro should decide how it should work however several distros might want to share this so it's a two way problem that's something I actually wanted to perform that's something that's very interesting for me so the question is how to solve this my initial idea basically would be to split the Python handling of RPM upstream and make this a project on its own that would probably live on GitHub just beside of RPM and people from different distribution could have access to and of course we would as RPM maintainers help with all the technical stuff but we are actually not that interested in getting into the policy decisions on how those packages are completed or processed or packaged because we just don't know and we actually don't want to know completely honest so this is something that would appeal to you like splitting it out having a separate package I mean basically having ten separate packages one of this would be Python and probably other languages could have their own repository or own project basically we started having an RPM extras repository which has not really taken off and we've not put in enough work to actually get it somewhere to basically push everything into that we don't want upstream but basically it needs to go somewhere at least other than some packages and some distros where no one else cares but there's one guy that retains the package but that's that's something I would push for in the next year or something it feels like it's something that would clarify the distinction of the encore and the packages at the same time I don't really see a use case where I wouldn't want all the extras to be installed together with up here this is not so much about not installing them although that could be interesting to actually not installing them in built routes that don't need them but for me there's more question of who is in control and who has ownership over the code or the settings and and RPMR stream just can't deal with all the different languages and be proficient in all the details and I think it would be good to leverage the knowledge from the distributions but not I don't want to hand over this to you because I know you will change something and the SUSE people will change something else and a couple of other distributions and after like two months we have five different versions of Python dependency generators that all do different things so we're going to be reviewing that stuff I mean like sort of how the leadership yeah we will still I mean we will not abandon that I mean we will still probably even own the report trying to figure out where is the fine line between like not sort of melting too much the project but also defining the roles of other people who contribute to the project yeah but I mean things are complicated deal with it but that's basically the answer but it would at least like set up the proper boundaries boundaries on how it's supposed to work and then you can still hit each other over the head between the distributions and I'm fine I'm fine with different distribution doing different things if they know what they are doing and they have reasons I mean there's a reason why they do have different distributions they are supposed to make different design decisions and to apply for different things but having difference just on the different sex that's not the game you want to play similar note I recently shoot with rbm build if something fail with rbm build during breath, install or build pace it's fine it's quite easy to find in development but once you hit the build pace or byte independence you are generated checks around it's like kind of magic even the dog phase because you write something like running running dog person dog or entering dog phase running script tmp and some random numbers and the script obviously doesn't exist in the time because it's created and merely deleted and if it fails in this phase you basically don't know why because even for the byte generators it doesn't say it's surrounding byte generators or it's surrounding this check so it will probably help me this phase would be more for both like I'm running this check for example where I can find the script where I can find the generator so I can say ok this actually failed in this script actually it's not magic it's actually black magic which you can sacrifice every time you run it basically somewhere else of course the thing is there are a couple of places in here and I will be more cold we are visited at some point we have rewritten most of the most places in rpms since I tried like 10 years ago but in rpms there are still a couple of places in our I don't know the blade will probably know but pretty old and all those stuff that needs to be cleaned up at some point especially when we talked about this earlier like the built-in policy scripts which are there are a couple of other things in there which are quite interesting but I want to continue on the on the perl language stuff so first is are there other languages that would be interested in actually maintaining their own stuff within our besides rpms so everyone else there other than python so russ already set up this way is it the fedora specific thing or you share it actually the nice thing is that basically we took one guy from magia I am from fedora one other guy from autos and basically we discussed how we won't do it yeah it's easier if you actually do it the first time properly yeah yeah that's a problem with autos fun that you have to maintain from these two decades at least I might ask you to move to get up if we set up more of those but for now it's fine ruby ruby jams have generated for a long time where are they packaged I don't know from top of mind I am not involved I just know it from this point of view so it's also somewhere in fedora yeah get to that piece there is also no gist of which is also the top of the figure there is no gist paging but this is a spec generator ruby which is not quite the same as the dependency generator you've been talking about it just to clarify because I mean there's nothing wrong like having a game of repository but it's there one more step removed from rpm the dependency generator which is not necessarily a bad thing just to know what we are talking about what's rpm's take on the spec generator's journey like there are various tourist projects that are outside of rpm obviously so they are basically all outside of rpm and they are basically not within our scope yeah okay basically so people that are involved in rpm development are actually not involved in any of them that's probably the first two problems one is that you cannot really specify in rpm like my build system is meso and then for the hardware you should figure out how to install the build section with all the stuff it would be very nice if we could have some build systems to make and we would do all the tricks inside and the second problem is obviously after using those two problems and also automatic build requires then you don't need any external generators because you have nothing to generate actually which actually means a question can we have multiple build sections install sections because if we have some like macro definition build system and then which would expand to some macro with a build and install we can have the second build section can we somehow merge all those build things now so you would there are a couple of things to consider the first thing is do we have multiple build routes or do we have like multiple software entries in build routes and if we have we could probably expand the macros, the macros it's not really a macro it's another magic thing probably with a different kind of cutout of chicken but we could basically expand it multiple times well usually you don't need macros in build routes probably for instance in my case I want to basically have a macro like a meson build system which defines a meson to install and then sometimes you also want to install some additional parts from it you could maybe create a macro in a way that it does this in some kind of like there is OS install post and we could have hooks for every section like pre build and post build and pre install and post install and then you would in that macro put everything in the pre build pre install and if install is empty it does nothing and it doesn't sound on you which is probably not the current case I am not sure but it does the build and if you manually add install it executes after the pre install and it should work it's a bit magical if you have like multiple way you want to build one thing then install second thing and then you have third thing you already find all those macros and if you install both you just redefine the whole macro let's see if we can wrap that up yeah I don't have what's the time it's 25 past now when is the coffee break then we are doing the coffee break so is there anything to conclude us or can we just head out for coffee I think it was a good break so we have coffee break we will start coffee break we will we will start by the next break