 So, welcome. I hope you can hear me okay. Sometimes I struggle with microphones and volume and stuff, so if you can't hear me just shout out. So, welcome to this session on line packs. So, a little bit of background. I mean, I think we've had quite good internationalization support in Fedora for quite a long time now. For a long time, Fedora, we installed quite good front coverage and input methods by default, so it's very friendly operating system for international users overall. And Red Hat has an internationalization engineering team, so we've been kind of focusing on that for a long time also. And at the same time now, things are changing quite a lot. The world of containers and modularity and different additions and different spins, different requirements. In the past, we also had different localized spins of Fedora. One example is some of our fonts, especially some of our East Asian fonts, are quite large, so sometimes this is coming up. It's something we can do to make our installation more flexible so that if someone wants a very small footprint, then they can still do that. So, this talk or presentation or session or discussion, I'm hoping it'll be a bit interactive and people will interject questions and also... Actually, I don't have a lot of slides and we have a few small demos and stuff, but overall, we're ready to try and get ideas and feedback and discussion about the future direction. So, basically the talk is in three parts. Well, the slide is a bit about the past, present and future. We actually made some progress on this over the last few years, like the change from young to DNF and weak dependencies and so on. So, already now we have various things in place that allow installation of blank packs and so on and even fonts now and also even input methods. I think we're going to maybe take this further. For the wider Fedora, probably the locale sub-packaging, which we were also involved in, it's maybe the biggest, in some sense, the most impact in terms of containers and so on, but it also affects many other things like the toolbox and things like that. So, maybe the first thing is what is a blank pack? Traditionally, I at least thought of blank packs only as being like translation bundles, but maybe that's still true in some sense, but we've sort of taken this a bit extended this now also to include things like locales and fonts, even input methods and so on. So, at least we're all kind of handling these now within this blank packs framework. So, how did things evolve? It's the first bit about the past. So, a long ago in the comps, I hope most of you are familiar with Fedora comps. So, basically, package groups. And for a long time we had different support groups for each language. So, each language had its own. So, there was French support, German support, Hungarian support, Japanese support. And then we'd list relevant packages, some of them conditional on some in those groups. It's an XML file anyway. But, and that was okay. I think finally now we've got rid of all those language groups because actually they weren't being... Well, they could only be installed manually by hand, the installer and other tools were not really using those anymore. So, to avoid kind of duplication or confusion, we've got a bit of those. And then at a later stage there was this special section in comps called langpacks, which was basically for installation of translation, like things like LibreOffice translations, man pages, dictionaries and so on. So, that was handled by some globbing and so on in that section. And there was, yeah, yum langpacks was a kind of extension to yum which allowed to inject these langpacks into RPM transactions and so on. But that didn't work with DNF. So, I don't know whether you want to talk about this point or anything. So, previously the langpacks were used by the comps. So, in comps, let me show you, suppose comps f29. Let's take an example of Fedora 29 release comps file. So, comps file is having this section langpacks. So, where the definitions of this langpack packages, yeah. So, this section basically defines what langpacks are in comps file. So, how this section is defined, like there is one base package and the base package name is written on the right side. So, let's take an example of LibreOffice. So, if you want to install a LibreOffice langpack, your system should be having this LibreOffice happen core package installed on your system. So, that's a prior requirement. So, likewise, these mappings are defined in this langpack section in comps file. So, if your system is already having the LibreOffice core package installed on your system, then whenever a new transaction will happen on your system through yum. It will automatically check if the respective LibreOffice langpack package for the default locale that you are using is available in the repository or not. So, if it finds that that package is available, then it will just pull that package into the running transaction and it will install it. So, this transaction can be you are just regularly updating your system yum update or you can explicitly just updating a LibreOffice packages. So, it will automatically find the respective langpack package and pull it. So, this was what happening when yum was there and this how yum was using this langpack concept. So, this was the very first concept of this langpacks in Fedora. Then, there was also groups section was there. So, groups. So, in comps also we have these groups are defined by language names. So, you can even install directly this language by saying that yum group install Japanese support. So, by that also you used to get the related packages to your language. And here the definition was like type the conditional. So, conditional means if this package xorg x11 server xorg was already installed, then and then only it's going to pull the ibuskkc on your system. So, likewise is the definition written in this comms file. So, you can directly even use to install the language supports using the group concept of yum. So, this was the after that. It was a need arise that we should have plugins that can be that can automate this langpack installations. So, a yum plugin written in python language that used to pass this comms file read the langpack section. And yeah, so and then the same thing that what I have explained you just before that it just reads if that base package is already in the transaction, then it pulls the respective langpack package. So, this was the second thing in this langpack's develop evolution. Okay. Then at the time of Fedora 21, DNA become the default installer package manager. Okay. So, then what happens that this yum langpack plugin become incompatible with the DNF. So, we tried to migrate the yum langpack plugin to the DNF langpack plugin. So, we introduce a DNF langpack's python package to the users and it worked the similar way the yum langpack used to work through the comms file section. Okay. But then again, we found that there is no way to auto install the packages. Okay. So, then this concept was developed like we should have a meta packages. Okay. So, we directly tell the DNF that just install langpack's hyphen jav package and then langpack's hyphen jav whenever it comes into the DNF transaction, it will pull the necessary dependencies of that particular language. So, this was the thing that got developed. I have this wiki page, small wiki page like C. So, during the Fedora 13, we introduced the yum langpack plugin. Then in Fedora 22, we introduced the DNF plugin. Then these are the some of the extra links that I am keeping on this page. Then in Fedora 24, we introduced the installation with RPM week dependency. So, what was this change that we utilize the RPM tags. So, RPM by that time got these tags like week dependencies. So, week dependencies are kind of a dependencies whereby if suppose some base packages already installed on your system, you can pull the respective language packages using that base package name. Okay. So, we are not using the comms here. We are totally going away from the comms file. Okay. So, this thing got introduced and we added a new package called langpack's package. And this langpack package then started providing a different different sub packages per language like langpack's AS, langpack's JA for different different package. And then we set these different different langpack packages to pull the respective language packages. Okay. This was the concept that we introduced in this change and this change was introduced in Fedora 24. Now, what advantage we got that we got a particular meta package that should get pulled into the initial Anaconda installation. So, we just requested the Anaconda team to add the code so that whenever a user selects that I want to install in Japanese, that langpack's hype and jam meta package will automatically get selected into the initial transaction. And then based on whatever the base packages are already included in that transaction, it tried to pull the respective language packages. Like suppose if the initial transaction of the Fedora 25 installation contains man pages as a base package and you have selected to install in Japanese language, then it automatically picks the man pages hype and jam package into the initial transaction. So, this was the thing that was introduced there. But I think there was some incompatibility keep coming with the Anaconda that prevented to install these packages. And then I think we totally removed the ISO concept DVD ISO concept from the workstation. The workstation introduced the live ISO concept. So that also created a problem for us because this meta packages only work if the actual package present in your media or not. It was not there so we again got stuck. I mean what next to introduce for the langpack's. So we keep thinking on that and we then thought that GNOME software is one of the way where we can try to pull these packages automatically. So I think that's a different discussion that Sandeep Anand will continue. Let me continue with the langpack's changes how it got evolved. So this change we introduce in Fedora 24. So in Fedora 30 then we decided that we will totally remove the language support concept from the comms file and let the users totally move to using these meta packages. So this was just small change we introduce into the Fedora 30 and we just remove the comms entries for the individual languages. And just let the users directly use the langpack's icon that particular langcode packages. In this current Fedora 31 release we added another change to the langpack's. Whereby we split the langpack's meta packages into the two packages like if there is a langpack's hypenja package it got split into the langpack's hypencore hypenja and langpack's hypenja. Now what will happen if you just install a langpack's hypencore hypenja it will ensure that your system will receive at least one default font and one IME input method. So that we have ensured while splitting this langpack's meta packages. Input method like iBus KKSE for jumpness. So can demo something like suppose so see so when you try to install a langpack's hypenja it is trying to install the base. Installing the requested package langpack's hypenja and then the dependencies these are the weak dependencies that are given at the end. So we have introduced this Google Noto Serif CJGTTC font as a default font and then this as I told you LibreOffice core is already installed on my system. So it tried to pull the helpja, langpackja and man pages was also there installed so it pulled the manpackja. So this is how I mean when you try to install a single package it will pull the dependencies related to that language on your system. I think it's already on my system actually I noticed this problem in toolbox so I need to check on the actual desktop system. Yeah I don't have right for iBus KKSE iBus is a base package let me check no it's not there so I mean if I was having a iBus it would have pulled iBus KKSE as well. So see like core so I'm trying for ODA language langpack's hypen core hypen over so it is trying to install the font package only and not the IME because again the iBus is not there otherwise it would have pulled the iBus hypen m17 in package. Being this a Indic language we have the m17 in key maps as IME so if iBus was there iBus m17 would have get installed in this transaction only but it is only installing the default font. And if I switch this command to install the complete langpack's package for the ODA language then these are the number of packages that get pulled into the transaction. It is there no yeah yeah that's something we are dealing with the Jellipsy people currently we have the bug open yeah yes yes that's why we requested I mean we need to discuss with the Jellipsy team and request them that let us allow to install it as a default Jellipsy local. So that's something is going on still in discussion. Yeah I think yeah that is what I'm done with this thing. So this F31 change is the one that we introduced that split the packages so we called it as a langpack score for ITN functionality so core packages will ensure one font and one IME for your language at least. Okay so that was the present so the DNF just recapping the DNF rich and weak dependencies that we are using for langpack installation and this new meta packages that we have. So I talked a little bit about I mentioned Jellipsy earlier and so for locales actually Mike is actually working upstream with Jellipsy on locales and things so probably I should say some words too but I was just more about the packaging side on the Jellipsy side. So firstly there's two well again I don't know do you want to talk about about the locales. The Fedora Jellipsy spec file a while ago we made some changes that sub packages are created for the different languages originally there was only one Jellipsy common file which contained user lib locale archive. And that was a huge file something like 105 megabytes which had the locale for all languages and you couldn't strip it down. I want only French and I don't care for the rest. And so we did some changes to the spec file that the spec file has auto generated parts with lower scripts which generate sub packages for each language. And now you can still install Jellipsy all langpack to get the big blob for everything but you can also install individual packages for individual languages if you want to save space. If you install all individual packages you have more data overall on your hard disk because the archive is more efficient but if you only need a few then it's better to install the individual package. So now you have a choice. The choice has become more important because the archive has about doubled in size. It's now about 210 megabytes because one year ago I updated the sorting algorithm to a newer version of Unicode and because lots of characters have been added to Unicode. And unfortunately the default Unicode collection order is duplicated in every locale. This cannot be shared not even if you use the archive. That's a Jellipsy limitation at the moment so that made it even more important to be able to install individual locales. And now as Parac has said this something like Jellipsy langpack FR needs to be pulled in when you install this meta package for langpacks. And because of the split into the langpacks and langpacks core something needs to be done with the dependencies in the Jellipsy spec file. So I think I need to do that soon after this conference. It should be pretty easy. I think that's about it. Yeah. So there's one more package. There's this dummy package. They have just like a minimal package which actually I don't think there's anyone from the Jellipsy team here but I don't know. I kind of proposed in a related boxilla ticket whether that package cannot be dropped because I don't really see that it serves much purpose. But anyway I think I could just do a very small demo. So this is actually for the sort of blue. That's in the toolbox. So this is yes. I'm currently using ENGB. In civil law we have the big old also workstation. We have the old langpacks archive. So basically contains all the all the Jellipsy locales by default. Obviously if you want you can replace it. What's a little girls eight hundred and sixty. And now in fedora base container we've dropped. Recently the EN US was dropped. English locales are no longer installed by default. Only C dot UTF eight. So that's good. I think that reduced the size by five six megabytes or something. I'm pretty tired. And this also reflected now in Fedora toolbox too. So the latest Fedora 30 Fedora 31 toolbox containers also we have C dot UTF eight. So that's a small change. I don't know it may affect some users but obviously you can easily install locales if you wish. So I heard Carlos talking about that too. I think it's not so serious. I think this image only went stable two days ago maybe or something. Occasionally you may get some local warnings. That's when you're running some application or something that's expected to run in a different locale or something. But anyway I think it's pretty easy to solve and it makes a very small basic image. Any questions or comments on this point? So Cindy is going to talk a little bit about GNOME software. So this is Fedora 30. So currently if you want to have line packs installed in GNOME software, are you going to talk about this on that status quo? No I don't know. Then I just wanted to show you how things look right now. So if you install, search for something like language or, I don't know, Hungarian or something. Then this thing appears. So it is possible to install these metal packages that Pac was talking about in GNOME software. I'm not going to do this now in silver blue because I'd have to reboot to get it to appear. But anyway, so that's the results earlier. 38 more matches. Anyway, maybe I'll come back to flat packs later if we have time. Ah, okay. I think I already talked about this so I can probably skip this. So yeah, maybe you want to... Actually we are working with GNOME software so that we can have auto installation of line pack data packages. So I can show small... Currently we are in simplified Chinese and we have three language packs installed. Brazilian, Portuguese, English and simplified Chinese. Now let's switch our language to some other local. So we are selecting Japanese. Here we need to log off and log in again to get into Japanese. So this is the small screen for naming some of the folders. Actually I'll be using my development environment to showcase this. So the code is coupled with auto updates from GNOME software. So it will take a minute to start the auto update thing. And then we can see how language packs are getting installed. Actually no notification or no permission, I mean no dialog box is there. If you are selecting your language in Anaconda itself and logging in. So the first time GNOME software will check for updates. It will install the language pack behind the scenes. Automatically. Right, exactly. And this will happen for language switch as well. So both ways. Currently no. Here we can see that language for Japanese has been installed. Can just run it again to show in the GNOME software. So here we have meta package installed. It will see then, it will, I mean it does a lot of operations. In the background it searches for the language pack. And then for that particular locale it installs the meta package. So that's it. Right. So just one thing, like if a user uninstalls the meta package by itself. Then this feature will not reinstall it. I mean the user will manually install it. Yeah, that may make sense. I think we missed, or we missed, I don't know. Well, I think Sunim just mentioned. But the idea of this feature is to kind of parallel how Anaconda does network installs currently. So currently if you do a network install, say a workstation or Fedora server, then you will get the language packs installed automatically. So the kind of user experience we wanted was that, so if you do a live install of say, I don't know, the workstation, then it will then post install that line pack, which would have been installed by the network installer automatically. And it will do it after. But I agree. It wouldn't hurt to have a little pop up or something. And originally I had kind of envisaged that it would be a semi manual process in a sense that it would be included in a GNOME software transaction. Like when you first boot up, say after a fresh install, usually there are updates and then GNOME software will say, oh, you have, there are 10 updates available or something. And then one of those would be the line packs. But anyway, the way it's been done now is that it's done in an automatic fashion. We may evolve this tomorrow in the future. Yeah. Yeah. And anyway, on something like, well, at the moment we, something like Fedora Silverblue, it would have to be a reboot anyway. So that's still, well, this is sort of the things I kind of wanted to cover in this exploratory part of the talk. How we want to improve this going forward. So, yeah, there are only a few more slides actually. There's not much time. So I can talk a bit more, but if people have questions, I'd love to hear any feedback or thoughts and people have a paragraph in the comment. Lossless. Well, I think the biggest change is that previously you do something like do a group install of the, I don't know, say French support. And now instead you just install the line packs FR. Conceptually, that's the biggest change. I could just say a few more words then. So for fonts, currently we're installing, so it's a bit like locale situation that currently we install lots of locales. Lots of, well, quite a good amount of fonts and also input methods by default. So one question is how, I don't know, another option would be to install less stuff and then install, post install more things later. And there's a bit of risk, I don't know, in the sense that, I mean, it does make it a bit more difficult for international users, but it also makes maybe the image smaller to download and so on. So they're kind of pros and cons to this and I think something we need to evaluate going forward. Do we want to only install a few locales? Do we only want to install less fonts? In fact, we've made some progress on the front side for Fedora 31 in a sense that it's now easy to get fonts installed afterwards if you're adding, or if you're in Toolbox for example, currently Toolbox doesn't use just the host fonts, so you have to install fonts into the Toolbox if you want them. And also one thing that we may want to do is to mount the system fonts into the Toolbox which would solve the problem in some sense, but however another way might be to leverage the line packs for that. I think for input methods it's less, I'm an issue in some sense. I mean, post-installing input methods maybe is not quite as big a deal. But I mean, not having fonts in locales is kind of a showstopper for basic kind of bootstrapping and so on. Actually the most controversial thing is about translations and this is really a very big and difficult show. Maybe it sounds quite simple, but actually we've thought a little bit about it in the past, but the idea is that currently most Fedora packages just bundle all their translations in it and so currently there are ugly hacks where you maybe just exclude, tell RPM, don't install translations for example, and in fact I think this affects, well, some of the things can also be done for documentation, but it gets quite messy then. If you want to enable translations then you probably need to reinstall the package and so on, so it's not very nice. And ideally it would be nice if you could only install the translations you actually need rather than 50 different translations. You probably only need one or two of those at maximum. Yeah, whether it should be done in some kind of enhancements to RPM or whether it should be done at the sort of build system level where we kind of do some automatic sub-packaging or other way of getting translations installed. But I think that's a long, it's going to be a long, well, I don't think we're going to do that anytime immediately but maybe something we can think about. Thank you very much. Thanks everyone.