 Okay, I want to start a bit different. I did a peek in my slide and there's one more point I want to tell about. And that's something that dawned on me a few days ago, which is pretty funny when it comes to features in RPM in general. And I realized there's an interesting distribution on how difficult it is to get some changes implemented. And there's basically a bathtub distribution. It's very easy for very small changes. So if you want to add a macro, no one cares. You just do it. It's in there. Someone updates. You update your RPM and Fedora is in there. It just works. No one cares. It's easy. And then there are really, really big changes that break the world, that require replacing yam everywhere, that will break the distribution and whatever. And they are also easy. We did Julian expressions and we just committed this and released it and didn't do anything and it magically happened. Probably some people did something, but we didn't. And magically all the infrastructure got fixed and it was very, very, very easy and smooth for us at least. I hear some people, other people had things to do, but we don't care. We don't care. That's like elsewhere. But the funny thing is they are middle-sized features and they are just impossible. You just can't. They don't have the huge benefits, like the big ones, but I have similar risks involved, like breaking somewhere randomly. And so they don't get so that the version comparison is one of those. It's in there for years. It's very small. It's a neat little patch. Only a few lines change. It's even in round six. Yeah, it's even in the back part of round six. But you can't get it in Fedora because, of course, it might break something somewhere. In the machinery, in the back side of the machine where you can't see, and no one knows what it might break, so they're all afraid, so you can't get it in for years. I mean, why can't we just do that just like the other one and see what breaks? Yeah, you can. That's what I even want. We refuse to do it. Who will refuse to do it? Vasco, I think. Why did you ask them? I mean, I was the one who first asked them. They saw it and first figured it out. Well, let's make a new law that benefits it. I didn't ask them. Who am I to ask them? I just implemented it. Actually, we got a patch from Susan to be completely honest. So they've been using it like for years. And, as you know, Susan still exists. So it should be fine. So here's the best and most funny part about all that specific feature. Remy has silently been using it for the PhD packages for the past two years. I've told nobody and nothing broke. So. But that's just, it's a funny observation that the middle thing is the hardest to get. So if you have ideas, please break the world or come up with something small. But not this middle thing. The problem is that middle thing seems to move around a bit. He's using it probably and nothing breaks because he wanted it all the way down to the real six. But the issue I discussed with the RBI ecosystem recently with the rich dependency. For everybody else, I had the issue that you are building on route seven package for Fedora 28. You're screwed because you will suddenly come to a Red Hat RPM config package which uses rich dependency. Then there is a request, Anubin, FGCC and RHEL 7 RPM doesn't recognize this. So the error message is unrecognized stack parenthesis if which is obviously, what a fuck. Instead of saying you need RPM with capability full or instead you need RPM bigger than version of something. We will be probably better. Yeah, the problem is that we do have those mechanisms but not source package files. They exist at the source package level. So if you're doing a rebuild against a source package you'd actually get the correct failure. Actually there is a mechanism because there is a request in the package and I'm requiring RPM build rich tabs but the problem is that the RPM parse all the dependencies together. So it will pass the, I'm reading rich dependency subversion. It's okay, I'm putting it in the set and then it will come to the and it will break. I don't know this. So what I propose is that the RPM should read those RPM leaves parenthesis something first and then say, okay, this is good. We will proceed further. So then has there never been a case where something like this would have been the logical conclusion to do this? No. Wow. Probably. I can't really surprise you. Not that I have any to do about it the 20 years on all packages but I guess that not because the syntax for the dependencies has not changed like ever. Right. That's the first time. We basically changed. Changed exactly once. Changed from. Because we also added extra grammar which it breaks on too, the weak dependency tags. Yeah, because until Hannah did that back port to like read the text in the first place. That's not a syntax thing. That's not a problem here because first RPM can also text it doesn't know. Yeah. So for binary packages. Right. And of course would break the spec file with an auto-stroke or error message like what the fuck is this? Yeah. And so that's a very specific thing that actually didn't happen because we never changed that. The truth is that those three dependency was a little bit fragile because previously even the weak dependency were present in RPM for a long, long time and a little bit tilled down. So they have been used only after a long, long year so the rigid dependency is starting after quite short of time like. Yeah. We've sped up the speed of RPM a little bit. Which is good. Yeah. You can only complete about one of those things. Yeah. The only issue is that nothing else changed to accommodate the fact that things are actually now moving at the proper development base. Yeah. It took us actually quite a while to get like Fedora infrastructure to move also with the pace that actually can keep stable. Yeah. I'm not objecting. What I'm objecting is that if you are speed up the pace you should have some mechanism saying you need this version or this capability to proceed with this architecture. Yeah. The thing is even if you had it wouldn't help you because it's already there in the back. No. The thing is you're actually fighting the problem with the old RPM. Yeah. You're running on the path. If you'll have media diagnose the problem. Yeah. I mean basically it's actually not doing something wrong. It's just not very helpful with the error. Yeah. Which is a feature of RPM basically all around. Yeah. We're going crappy error messages. I mean at least they now come in color. Yeah. Yeah. Well so now the crappy error messages come in color. Yeah. They use backpicks. Yeah. You get this message from John and those from RPM. Well yeah. Yeah you get it. Well I'm not trying to say this situation. That's doomed anyway. So I'm trying to say situation when after three years from now it will include function teleport inside RPM and current RPM doesn't recognize it. So I'm trying to say situation for the years. So for the general thing with RPM is we've always guaranteed background compatibility but not forward compatibility. We're just in shape here. And you basically can't. If you start doing forward compatibility guarantees. You lose every other game. You basically you basically you basically stop moving. Yeah. And I've seen a project that tried yum for example and they have that now for this reason. Yeah. Yeah. I'm just not really for better. Again we'll meet the things right and we have to do with that or not. But more. I mean the simple trick of like processing the RPM live stuff as these first querying for those capability and supported is not a bad thing but the problem is right now that I think every high level package manager actually ignores all those. Yeah. So like they don't read them. They don't actually even see them because they're not exported by so like there's no point to investigate them. Yeah. So all those tools would need to be changed. I'm not saying that it's a hard change or anything like that but we don't actually have a mechanism right now. I mean they are stripped out of the data with the argument that well it's basically redundant if you're running your package source from the wrong repository you're doing anyway. I mean I don't think that's quite a fair. Yeah. But I get it. But I mean there are a lot of them and they are in a very package and so it saves a quite some lines. Yeah. Although I mean I don't know if you actually have a special collection at the top that I could just read which ones are in for a repo then that would actually be a neat optimization trick because if they're the same everywhere and you can just say the maximal subset of all capabilities that this repo requires then you go there. One issue I have I hit it so fast when you accidentally do something quite you put into the post pre-inst a script you put something like exit one so you screw your script pre-inst in pre- uninstall yeah then there is no way to to fix it because even if you fix next version of the package RPM always try to run the pre-inst script of the previous script and the administrator had to manually step in under RPM dash erase dash in all scripts so every admin in the world have to do that to fix your mistake so it would be nice if if I ever do something like that I can somehow override this mechanism and say don't run this pre-inst or something of the previous script so I think I can screw at some point suggest that having an update script which would also make a lot of other things much less ugly because you wouldn't reuse the script that you assume are for install for that kind of thing as well yeah, you could if you start getting into weird states though because now you have to separately consider what's happening for those stages and then now you start having the requirement you know maybe we need to have the delay script execution so things actually run correctly all the time because the way that transactions can happen that's not necessarily easy to do currently because of how ordering actually works yeah transactions get really funny if they're for property and that's probably not going to work yeah the transactions get really really weird when you start talking about anything that could cause the breakage where you want to like split or override script operation because you don't actually know what other things might depend on it it's a difficult option to expose which is why actually I think only one I don't know if I can remember exposes it at all and they expose it in a very very slight way because it gets very meaningful and it requires knowledge that an admin just may not necessarily have about what decision to do to make things like that yeah I think that the right thing would be to have some type of override that was used to the next like it would be a like a transaction flag that you could push and say like feed this as a factor and then no you don't want to have a transaction flag cause that's something that users would want to have that night as part of package package package basically yeah well you could put it as an argument for the script load like if you're overriding the same script load from an older package just as a you know I don't care what happened in this old one don't want ever yeah my guess is this will get interesting soon as soon as you think about obsolete and whatever and which package actually meant but maybe a 90% solution is better than none yeah because doing things by running around typing commands is always paid and really right with there well what we can do is well there might be some easy way like just define some macro which is writing some temporary file like in great trance like the nbr and for instance do not run post-on then basically each trigger will check if such file is used there and if it's there then you are capable of you don't want to be disabled for 4 to 1 nbr and then you basically you don't think you could also just attack and put it in your head or well the problem with the new thing is you would need some time to report it everywhere and with just simple file we can do now nah almost yeah much social really probably easier to just have to take and evaluate attack on one time and then filter out all the script parts shouldn't be done because the thing is you could actually use the full strength of the dependency system for that so to prevent foreign script parts from being run oh yeah you could basically just cancel script and then for so like inverse of the of what triggers they just nullify scripts give us the inverse trigger yeah nullify script if this condition is true because because triggers are not horrible enough yeah well I mean you're describing triggers except the other they do the opposite of that you want to write it up yeah yeah write it up write it up can you just want to ignore all the script because there are cases like obsolete's case actually this would be helped by it because in obsolete's case a lot of times when you replace one with a completely different package and it happens to have the obsolete's these scripts that execute in that case are probably not actually going to work correctly because in many cases in obsolete's isn't necessarily going to include or provide meaning that they often are but like giving the ability to deal with that last bit by saying like in this case you're triggering based on the fact that this condition is being obsolete like just nullify all the scripts that's actually a pretty easy way to like just avoid that if it turns out to be a problem yeah right because you can basically match all other you match all conditions in all conditions you can match for different lanes congratulations we have a hundred percent solution somehow that was just too easy you'll probably find five other things that are wrong with this as long as you try to implement it but it might actually be not that that's another thing that's insane up here if you have a problem there are two basically two ways this can end up the one is you add like five lines and it just works the most more common version is you have to rewrite like three subsystems and then it's still not quite there and then there was a title somewhere that becomes AI and to add more fun to it there's no way of telling them a problem in advance okay so another easy thing easy what I envy Debian work is that they're probably installed okay or somewhere that we have we have the macro underscore install length where you can decide which locale can be installed but you have to define it somewhere the macro and you have to know which locale is installed so somehow first print it and then something macro while Debian work has some command where you have just nice and keywords menu which will do this and we will just click I don't want these locale like Italian Chinese and so on so you're talking about Debian well it's Debian it's hung by Debian as well but they have standalone application as well and it will delete all installed locale which I didn't select like the Italian and next time I'm installing package it will don't install Italian locale so basically we're missing the part where like you decide to set install lines and I want to retroactively purge all the crap if it doesn't match that because our people already know and somewhere it will define the underscore install lines with those lines that part is easy the part you're asking for is like retroactively purging actually it shouldn't be that difficult because if you're using the Boolean dependencies you should be able to do that and I think most of us already reoriented around the Boolean dependencies for like that should actually be already like 80-90% there basically just missing I don't know about the details I've not looked into this the last time I checked this a while ago but they were actually already using Boolean dependencies for this and actually DNF should be able to prune them if the matching packages go away yeah so what I'm just missing is a nice user interface you'll allow me to do that sure it's not about real problem yeah all right well there is there is still the case of when people are using find lines they don't break out the lines into separate packages and stuff that's where like if you set install lines you want to have a way to just go back through the archive data to encourage old things that don't match your language because our game stops caring about those files anyway once you set that so purging them is not a big deal it's not easy to find that information because it's not like something you think about or know how to look at the database for it but a tool for doing that would probably not be that bad I'm all open to adding more stuff if it's really needed but one of the hope for the Boolean expression was to be able to solve issues like this in a generic way from an open aspect by setting up the packages to probably connect should be more professional doing the tooling on the user land side so while we are at the Boolean stuff wouldn't be easy to add Boolean provides oh boy we just had this kind of situation it did I'm not aware of it so so I did think about this and I decided not to for a reason the main reason is it requires RPM to actually do solving to be able to check that whether it can install a package right now RPM has a very simple check whether it can install a set of packages it basically just evaluates each Boolean term and if it's true it's fine if it's false it's obviously not wrong and it's simple to implement it's also simple to understand so while the dependency solving is complicated checking the result is easy to see if it's if this is working if you have the Boolean stuff on the on the provide side also it's not at all trivial to decide whether a set of packages is insolvable we effectively would need to solve an RPM yeah basically yeah but I mean I mean it's not only an implementation problem it's also a problem of people figuring out why it's not working everything is starting up because I have a package installed that has a provide that's conditional or something I want to install yeah and I want to install this this is not yet provided oh god but if I would install it it would be right oh that's basically all those all those provides are now basically they are just there and then they would but then it would basically split up into a quantum state and you basically have to basically have to decide for each of them which value they do have well the workaround we want to do for this is empty packages empty packages yeah it's a package without files that just requires some two packages yeah so we have the same basically same problem with RAS because there are so called great features yeah so exactly the same point so basically what we have decided we cannot do it in RPM so we will just which so the main package will just depend on free food if these packages it's also the packages will be empty but the package is empty and if we can get out one generation of packages then it won't be so painful for you anymore it's now like you have to create 15, 20, 30 packages maybe yeah we need a spec generator anyway yeah once you know some of the spec generators that are out there would actually horrify you in how they work so don't ask for things don't know what the consequences might be don't ask for things that you don't understand what the consequences might be because they're kind of horrifying all well I'm only asking for RPM to be a super set of what the Python ecosystem already has yeah and the basically environment markers and all those things they're the same kind of tricky problem with Rust but the core issue for doing it is that if we turn provides into expressions that evaluating them becomes so painful that it actually might not be possible to debug dependencies anymore that's what it comes down to if you can't debug dependencies then what the way to tell RPM fake things to be able to get expressions that you want to know and there's not actually a way to really do that okay I mean it could be done but like that's a lot of work that possibly could be solved in a different way like the the way that the Rust creates are doing it right now is that they do with the with the provides and requires statements with clauses so that the same package must provide all of those things together and so we basically avoid having to have provides map because the requires says one package must provide all of those provides together which we haven't recently yeah well this was the reason why with was added because that way we could avoid having mapped it provides because that was the alternative somewhere at some point how to do that yeah I wrote it in a mailing list but in retrospect not it's the best place to put that can you re-send this to me and can put it up on the rpm or yeah I can do that website yeah because he does well to have some examples of like why you use because that's like a fancy expression we added in our 414 precisely to solve this problem because rust was really hard before that what what Igor wants to do is another way to do it and it's technically more efficient there's multiple providers of a feature but in practice that doesn't turn out to happen that often in most ecosystems the only ones where this kind of happens in is rust and go and go is stupid and rust actually has a bunch of different ways of dealing with this problem internally and a lot of those can be flattened into expressions that we're already using in RPM to handle this so it's only kind of edge-casey and in most cases Igor just winds up upgrading dependency anyway and so doesn't care anymore and so but yeah in the Python case and I think most ecosystems are using the width dependency to just match the markers so that they all bind into the same package and yeah I'll send you I'll re-send you the link to my available post which explains why we use rellib and I'll write a small verb and what we can put that on the RPM work site so that people know about this because that is the reason we added that dependency there are a couple of interesting things that can be done with this brilliant expressions so maybe talking through your case yeah I don't understand how it would solve so you have solved for everyone to get it so you have a package that gains a a provide a feature if it is combined with another package yes that's basically yes the issue basically you need something that represents basically the space between those two packages for example I have that gains PDF support if PDF renders it yeah so obvious thing is of course having a small package that represents those bridge which is annoying but obviously works and so how do you do this with Rust so we just check the versions so basically there is for example in the requirements like I need version which is combined with 1.0 which means you want any version between 1.0 and 2.0 2.0 would be impossible so we specify some like speculators create full more equals 1.0 with create full as in 2.0 and then if we want a feature package on top of that we wrap that in brands and say with the feature for create which means we specify both clauses and then then after that to solve then it checks against the second clause which is the feature that we actually request but you're doing this in the requiring right we're doing the requiring so that's basically the opposite thing of what he wants he wants to provide basically everybody wants it yeah everyone wants it so if putting it in provide B2 catastrophic that would be already probably decided it would be can we gain a new thing for RBMs that would specify extra features or is it just an overkill and we should just think of sub packages you can probably just write a reminder that creates a sub application yeah if we get markers that creates sub packages I fear I fear we can actually do that so the kernel does this a bunch of actually a bunch of packages have sub package generating macros it's even worse the debugging for packages used to be a macro it's kind of still it's let's get a little bit more specific macro high it's really not ideal Python dependency generator yeah can the generator itself create the sub packages we were you're going to I'm going to have to write a description about this for you because we were talking about this earlier so basically automatic package creation is on my back of my mind for quite a while if not really just a couple of open questions how to actually do that and they have been discussion with Panu if we really want to do that because so it basically is one of those control questions the question is who's controlling how the packages going to look like is it in control of the package or is it in control of the distribution that provides like the patterns for the sub packages or is it both because it can have overrides or yeah so that's all still to be determined yeah so a lot of things is that I'm going to at least a design proposal for Florian to figure out like whether this will actually be workable in a way that doesn't make everyone's heads explode for having the sub package generation because it's actually something I want to because in one of the distributions I work at Magia we split out every goddamn library into its own sub package and so it takes a lot of work and it's a a lot of a lot of a lot of a lot of a lot of a lot of the list of sub packages gets really big once you start you know dealing with a lot of stuff you could also like split out instead of libraries like no arch files and stuff like documentation documentation language packs automatically there's a lot of there's a lot of things that can be leveraged it's just a matter of like figuring out how you want that to look and how you want the mechanisms yeah the problem basically is that the spec file itself is basically oblivious of how actually the package looks so you don't have a file list this is only generated basically after the spec file is parsed so so questions what's the workflow there but at some point you want to have that and that's definitely definitely one of the clients for the future to be able to specify how sub packages will make sense to kind of formalize what we would like to gain but the Python extras requires and give it to you so you can then compare what you are preparing and obviously you can just see the four of us together yeah I think we might want to implement it using macOS first for a spec generator first to see if stuff actually works this way and then compare nodes so if you want to look at an important spec generator tool as much as Florian is going to kill me for mentioning this auto spec is actually one example this is from Intel and what auto spec does is it builds the package over and over again it analyzes the output every time it changes the options to figure out what all the sub packages are following a pattern list to identify how it's constructed and it ultimately produces the final descriptions done license determined and then spits out everything internally consistent but it takes hundreds of runs to get some packages to get there this is the reason why nobody wants to do this because the problem with it is you're talking about mechanically understanding software and so the reason we're not talking about full-blown we don't we have one line and then spec magically happens is because of that no what I want is basically take all the information that's now in spec files and push it to the upstream metadata well that's a different problem because the upstream metadata has to actually be sufficient for that to work well yes but we have some control over that actually do you? yeah I'm a Python developer right so I mean it's still you still have the ecosystem to argue with and I mean argue well definitely yeah that's a different topic but it's our own domain so the way it's on us to argue with it I mean if you want to push that metadata there then sure it's probably not a bad thing it's also a problem in the Python ecosystem yeah the thing is it has lots of problems with all the faults that RPM has it does some things right oh it's so much better and and I guess some of those kind of packaging systems can still learn the trick or two like doing proper dependencies yeah for example this this is actually a big issue for RubyGems because when we were rebuilding all the gems in copper it's like 80,000 packages if the policy is if you don't state license it means proprietor so the game to spec actually add add at that point and reject to proceed so if we somehow get for example for gems the license back to the RubyGems then it will be awesome even for few hundred packages that would be awesome so if you will start that in Python land and you will have somehow to do that and we will do that well RubyGems the main problem with the license is that every single distribution and the upstream uses different licenses so for example for Rust in upstream nowadays there is a check for SPDX but it doesn't mean because in federal for example we have ASL base 2.0 but the SPDX format is Apache dash 2.0 well you can always well do some translation the main problem with that is you need to find the license actually so if you find in federal that the license is GPR and it's only missing in the metadata and it's easy yeah that isn't actually your case is absolutely fine and so it's unfortunately is this was a bad example the bad the good example where this goes horribly wrong is BSK and MIT licenses where Tom is going to drink because there's almost 100 different variants of all of those and the problem with that is that in SPDX like every single bloody variant has its own tag and the distributions that do use SPDX this problem is fine they can map up to a land where we use the Pandora Pack system we are not insane enough to have to try to identify every goddamn flavor we just call it BSK and MIT and all of the day but this means that our data is actually inadequate for upstream systems yeah so like that that's one of the reasons why this becomes a big problem because if we decide that we're going to move to SPDX stuff which is a conversation that keeps happening over and over again okay actually has to get into one of the more recent ones when we were starting to talk about Rust and yeah that's a conversation but if we want to start talking about doing that which is a different type of problem then that makes our data a little bit more valuable if we want to push that into Python or well Python uses our system which is a different problem Ruby and all the other ones it would make sense in that case because you can't guarantee that they're going to be consistent between the two systems at personal like for some of the big major ones like the copy left ones and the ones that are formulating permissive licenses yes but everything else no and that's the problem is that increasingly you have more of the less formulating ones than the more formulating ones because they're just that's just what people want to do now you know being mostly corporate environment developers that feel more for that kind of stuff it becomes actually harder not easier for us to be able to provide a value in that sense we are probably running out of time so let me ask you yeah we just showed to the audience project which is my pet project because I'm doing training for newbies in RPM so explaining them what RPM is and all those basic like URL name and version so yeah so I create this wizard which is like really for newbies so you start video petitioning full and you have the link to the guidelines how to grab the names version four three five and in the end you will get some swag yeah so it's really a part about if anyone a spec wizard is not quite the same thing as a spec as it is and what's like you have to figure a spec bit this is probably way full of ah yeah dynamically figuring out what everything would be but this is something I'm working on any output I think I remember some