 I would like to talk more about cross-disk collaboration which is not very popular thing to talk about and it's not really happening much as I wish. So why do we actually want people to work between different distributions? Because we're basically wasting packages time because they have to package in one distribution, in one way, in another distribution, in a different way and it's just getting crazy. It's also confusing for the outside people who want to start contributing something like whether to use software or actually contribute some software because it's like, oh you know I have Fedora here and I have to do it using these guidelines but it won't work for open SUSE so I need to do it in some different way. So that's not good for the community either. So let's take a look at some Python and open SUSE stuff. Yeah, I even have the Internet. So basically Python is packaged really differently in Fedora and open SUSE. So for example in Fedora we have this simple spec file which has a bunch of build requires. We have Python 2 subpackage which should die soon but we have it. You have a bunch of build requires. You have Python 3 the same thing and you specify Python 2 by 3 build and then you basically duplicate sections for Python. For the open SUSE it looks like this. You just specify Python module whatever and Python build. You don't have any subpackage, you don't have any duplication, you just have it in one place and it just works magically. But the magic is really horrible inside if you look at it. So like after we go through the whole ecosystems I would like to choose some example of some language and talk like how can we improve what's good in one distribution and what's better in another so we can build something which would work for all of us. So Ruby, yes, I see you. I don't know the entire story behind the Ruby because at some point I heard that open SUSE people actually wanted to use Fedora packaging but they didn't like some aspects that tried to change Fedora packaging but there was some conflict so we ended up with different ways of packaging. So I took some random Ruby gem where we have some awful stuff in the build and install and some copy manually stuff and run checks. I mean I can read it but it's not that nice. While in open SUSE you have this spec file, basically you just run gem install and gem packages and it generates all the subpackages, it basically runs all those commands. I know this one looks for me as a person who has no idea about Ruby, it looks much better. I don't know was the reason why it was so different and why it was not contributed back. If you know the story you will tell us later. So for the rest I'm happy that it's actually same because basically we have absolutely the same spec file so basically if you take this spec file and compile it on open SUSE or do it other way around it will give you the same results so you get bunch of packages and you just have a few simple macros in here basically if you look at the open SUSE package it's basically almost same except for dynamic build requires you have all those bunch of packages and all the macros are the same. GoLink is yet another level of complexity because recently Nicholas started to rework GoLink packaging without talking to anybody outside and even inside of Federa so it's just over complicated even in Federa it's not consistent so I'm going to skip that part. So just some useful tips like when you want to start some project about something anything related to RPM packaging just talk to people before you actually start working on it because I figured out that many people don't know about some RPM features which they could use for example generating the runtime requires on the files and things like that. Just talk to people and they will help you. If you actually started working on something and you decide oh this is a really bad idea I need to change it don't just yeah I'm doing this change I'm pushing it to Federa I'm done. Basically talk to people from the other distros which are using your code and make sure that they are aware of what you want to do take into account their input what they think about this change and yeah so another thing which can help with this is basically you need to get some common place where you can talk to people so for example in case of Rust we got Federa Rust RC channel where we have actually guys from OpenSuser, Magie, Debian on the Federa Rust yes they are also contributing to some extent. If you don't really have some place some strong opinion where to put you can use RPM ecosystem mailing list and there is even RPM extras Git repo so basically idea was that you have some your ecosystem and you can put here all your macros and this package could be shared between the distros but nobody put anything here so far yeah there are some bunch of scripts which are different between distros I know I don't like this situation but it's just people should go there submit pull request and other people look on it and basically at some point you will get to some point where you can share the code between distros yeah don't try to be too clever for example the goal and packaging it's just a bunch of Lua I know probably more than thousand lines of Lua which is rewriting spec inside multiple times somehow so instead of just going to the RPM and asking them hey I want dynamic sub packages I'm missing this feature I want to do this can you add support for it well RPM is different than it used to be like probably seven years ago it's possible to change it it's not that hard you just need to talk to RPM guys and file tickets and we'll get some stuff done because we got dynamic build requires we got tilde we got carrot versions I know we got some kind of new rich dependencies where you can specify I want package who more equals one zero zero and at the same time less than two zero zero like people were trying to create some work around using conflicts or multiple requires or things like that but we can get it better yeah and obviously always talk to people so now I'm getting more to the details do you have some preference which language were we should take and talk about it will be Python Python okay so basically one of the things which I kind of like about open Suzer and not really nice in federal is that basically the idea is in federal we ship only one Python free full but in open Suzer they actually build all the packages for all versions of supported pytons is that something what we would like to do or it's why not yeah they do it same with the Python but you you build a package for multiple versions you run the test for all Ruby versions and but you can exclude some some version of Ruby and say you mean for the interpreter or for the like packages site I think if you would actually magically turn on multiple builds people will actually try to fix them no but then what is the reason why do we actually package those things if we actually have four other versions of Python we want you can because it's not about installing Ruby or Python it's about the application which is written by a chance in Python and Ruby and you want to have the nice I don't know what is written what applications written in Python for example you want to be able to install the well there are things which you actually cannot do people install well it's not really system-specific but because people create the bindings but they don't publish on pipi that's actually problem I think for every ecosystem so what I would like to get rid out of in those spec files I don't mean in PBR but yeah nowadays we actually generate automatically those requires actually not many people know that we actually do that so if I look at the some Python oh sure better I know some so basically those those dependencies are automatically generated but for some reason people still still put them in the spec files manually so probably one of the things we could do is basically clean up the stuff because actually in openSUSE they implemented this dependency generation I know two three years ago so basically one step to get closer might be so if we're looking at Python I had somewhere open it here I know probably one thing to make it a bit better and all let's we can define in further a Python build which will be Python free built in the end I know what this Python expand does to be honest we can create some some shims for it so we can actually share share the packages basically they have since they have multiple versions of Python the for each version of Python they want to execute some common so I guess this is like changing Python side leap to every version of Python and removes the directory in there well in federal we can just say Python expand is macro which expands to nothing so you would remove just that one there so what else yeah another thing which came to my mind is why don't we actually generate the file list automatically because for example in Java they actually do that so they after MVM may even install they actually it automatically generates some file which you pass files minus F why don't we do that no you want you won't know about that what about to for example Amazon I think they created some tool in Rust which is actually going through the list of the files and tries to think is that license file is that license file so we can actually use something like that to detect well you do because you run unpack for some tables so what are you trying to guess there well so actually in Rust there is some special field like license file and 3D me file or something like this it doesn't work if you have multiple license files but that's different story so basically what we're talking with the RPM folks is we can actually implement something like this in rpm so basically you can get most of the parts like license and probably read me it might be sometimes not working properly but do you really care if some of the files isn't marked as the license which should not be like is that really big problem so if I if I understand correctly basically the license was invented because people do minus minus no dogs or exclude dogs in the installation so they don't get license file which is probably evaluating some some licensing so they decided to have license which is not getting excluded when you run minus minus no dogs so I would say it's really minor use case and like it's better to to have some wrongly identified files marked as a license because it won't affect probably some really really minimal installations which actually wants to exclude documentation for example well but you check the licenses like you are talking about the like license field not like the license like person's license or both I'm pretty sure I know 500 packages out of relate don't have license files in the person's license but they have it person dog I'm like I didn't look at those packages but I'm pretty sure they're like that no it's not because of the review but because it's not automated so if you want to change some dog to license so you introduced new field and that means like somebody has to go everywhere and fix it and if you have some kind of auto detection you just change that part which is automatically detecting it and marks its I'm not sure if you can define standard but you definitely can you can get it correct to some extent yeah because basically even talking about Python where basically there is that project about creating dynamic build requires like you cannot like people are not going to validate all the requires which are generated automatically whether it's build requires or requires they just rely on that they're correct there most most of the time they are they are but sometimes they're not so I think the licenses yeah but probably and is there something for Python which says this is the license files so let's propose it to the Python but you can convert it well you can convert from spdx to Federa like not the other way around but from spdx to Federa because we have just bsd in Federa but the spdx defines 50 of bsd's that's actually what we're doing the Rust RPM so we have this bsd contributed that that file which is yeah I know how it's generated to be honest but basically you have a list of spdx and the federal license and probably some comment no it's not it's spdx to federal license list well because you cannot generate license filled in the rpm so it was we can definitely create some macro in rpm which says spdx convert and put spdx identifiers there and Federa will have federal names would that work what do you mean no it will be because macro expands yeah but we don't have many things in the spec file which are in srpm why you don't need anything extra like you don't need the files to put something the license list yes well we have to store srpm srpm for the legal purposes so the srpm is the source not like G3po for example dynamic bill requires is kind of similar to the license field because you need to have bill requires to start the build but it's not necessarily true because you can now generate it so you need some bill requires to be able to generate another bill requires so we can make for example this well whether it will be just macro which is converting spdx names to federal names or does some more magic we can do that so are you going to submit some pep something like proposal well it's it improved I would like to get it in the rpm instead I would I would like to get it in the rpm properly well it it's improving because I remember when I just started to contribute into rpm like that till the support in federal it took I know 10 years to get it and it was reported to I know rel6 because it was the concern it's actually improved now yeah but we don't have to be different in this case do you have some some example of the proper one because I just took random one which was updated not so long time ago so basically I was talking to the Susie guys yeah it's you're sure okay so basically the whole thing what I wanted to say is basically the Susie guys I talked to them on the open Susie conference in in May in Nuremberg they were open for any changes they were open to actually get it in the rpm upstream to have some better way of defining sub-packages or do some crazy stuff and so that will be more closer so probably from federal side we can also like for example if we want license file let's get it in the Python upstream and then get it in the rpm upstream so all distros benefit from that would it work we can in federal say that we are not going to build them like the macros will be same everything will look same but in federal say we're not building multiple versions we're building only one version you would still have yeah like is that the problem or don't remind me about all the config please