Hello and welcome. My name is Robert Engel, I'm working for SUSE since 18 years now. Currently I'm working on SUSE Package Hub, so that's the topic I present to you today.

So Package Hub is mainly about how to bring open source packages in the open SUSE build servers to the SUSE Linux Enterprise customers. So when I talk about Package Hub, it's all about packages.

So usually if you are using open SUSE Leap or Tumbleweed, you can choose every package which is available in open build servers and install it on your distribution. This is a little bit different if you are using SUSE Linux Enterprise Server, because

usually you want to also have support and so on, so you basically are bound to the packages the vendor is shipping in this example at SUSE. So this is basically the situation that there is the open source universe with a lot of

packages, and there is the enterprise universe where you have only at least a limited amount of packages available installing on your server.

And if you want to install additional packages, you can of course use the build servers and search for packages that are building for the SUSE Linux Enterprise Server, but you run into several issues or challenges.

One challenge is you can't really identify if this package is not in a way harming your system or is not breaking supportability from SUSE. And actually you can't be sure that the package is actually working, because you find so many

projects in the open build service that probably build the same package. So there was an idea to create a project where basically many packages are hosted that

can be additionally installed on the SUSE Linux Enterprise Server. And of course in an easy way. So one idea was to integrate this project also into the delivery channel how SUSE is delivering enterprise products to the customer, because everything has basically gone through

the customer center. So it would be a good option to also have something available for the customers that they can just click to activate package hub, for example, and then they have all the additional

packages available. So this graph shows roughly the numbers are not 100% correct. But just to give you an idea how unbalanced the number of packages between several distributions

are. So we have the SLE-based systems, which is the blue one, which is kind of like 2,500 packages. When I talk about packages, these are the source packages. And then we have the LEAP-based systems, even more packages, and of course factory

has the most amount of packages available. So what we are trying to achieve is basically closing this gap to bring more packages to the enterprise customers and basically the users.

Well the current situational state is that we have around I think 900 and something packages available in package hub. So we are getting to our goal, but in just slow and tiny steps.

So it all began as an idea setting up the project, and the project needs to be hosted somewhere. So the idea was to use basically the open build service. So I guess all of you already know the open build service, right? So please raise your hand if you do.

The second hand as well, if you do really, yay, okay, you really do. So the easiest way was basically to create a project there, because then everyone else is able to basically add packages there.

So there is one great advantage for the developers who can just contribute to package hub, but there is a disadvantage that basically the customers are not really dealing with

the open build service. So usually they get their packages and their software through the SUSE customer center. So we thought of, okay, let's combine these things, and you need to know that when

I talk about package hub, this is usually the customer view. So in the SUSE customer center, the customer sees package hub and he can click on it and he gets the repository. But from a developer or maintainer perspective, in the open build service you don't find or you won't find a project that is called package hub.

In build service, the project is called open SUSE backports, SLE 12 and SLE 15 and so on. Just keep that in mind if you are looking in build service for package hub project.

So with this approach, we can make sure that there is easy delivery to the customer, and also the maintainers and developers are able to coordinate and collaborate on the project. What is most important is we can also establish checks to make sure that any package that

goes into the project and is then delivered through SDC to the customer is either not delivering the system and the customers are not losing their supportability.

So basically that, for example, packages are not conflicting, like on a package name level or on a package file list level. You need to also know that since it is a community project hosted in the build service

but also maintained by SUSE, SUSE is not giving support, basically. So we are doing this on a best effort base. If a customer has some problems with some packages, and also the customer knows that, but still some customers are using it.

For example, we have some requests where we put KDE Plasma 5 into SLE12, also in SLE15 in package hub. But we wanted to also have the opportunity for the community that they still be able

to maintain the project in a way that they can add packages and work on the project. And of course, that's why I put there a question mark, community support is also on a best effort base.

So these are the main features, and the most important one is also it is not conflicting with any SLES installation, and it is also cross architecture. So we have all four architectures available that are available on SLES.

So this is x86-64, ARM 64, PPC 64, and of course S390. Not all packages are available for all architectures, for example, KDE Plasma 5 is not available for S390 for certain reasons, but you are free to port it if you have

a use case. And remember to look for the OpenSUSE Backport SLE12, SLE15 project if you want to look into the build service, what packages are in there.

So that's about basically the current state of the project. We also added container support for package hub 15 so that you can submit your container

and then it will be automatically available through the OpenSUSE registry. So if it will be also available through the SUSE registry, this is something we have to discuss. So how does the future look like?

There will be package hub for SLE15, so this is something we are currently working on. Also we want to make sure that there is a migration path from SLE12 to SLE15, so if you use package hub in SLE12 before, you can just migrate to SLE15. We have to deal with some challenges there as well, because some packages from package

hub can also be migrated to a Linux enterprise server-based system, for example, or to add-on product workstation extension. This always can happen, so at least for the free add-ons for SLE, we want to make

sure that the packages can be migrated. Then Docker images I already mentioned. Then one more thing is Ludwig also mentioned that it will be, or it is a good idea to

have something like a migration path from LEAP to SLE, and this also involves package hub in a way that basically you want to have all the packages you installed on LEAP also available for SLE because otherwise your migration would fail. This is something we are also trying to achieve, to put as many packages as we can basically

from LEAP also into package hub, that there is an option to really migrate from LEAP to SLE without, like, at least most of the packages can be migrated.

Of course if the packages have some conflicts, they can't be migrated. So, also it is quite important what you as a community or a maintainer like to see in package hub, so let me know what you want to see on the future list or if you are missing

some features so we can talk about that. And, of course, if you have any questions, oh, there is I guess I already won. You can just ask now.

Do you have a microphone over there? Okay, thank you. Okay, any questions? Okay, there is one from Andreas. So far one rule has been that the packages that can be submitted for package hub need

to be different from those that are provided already as part of SLES, right? The question is, basically the rule is it can't be the same package or a package that provides the same files that are already in SLES.

So what I would be interested in is having additional GCC packages in package hub, but obviously Zuse is providing GCC as part of the SLES product and as part of the two-chain modules and so on. Do you see any path forward that we could go about this and say, you know, like submitting

a GCC 7 or in the future GCC 8 package to package hub, but simply excluding the packages that, like disabling in the build service certain sub-packages that are already part of SLES? Well, what you can do, I mean, it depends also for what you need GCC, I mean, if it's

only for like building packages, that shouldn't be an issue, because if it's only during build time, we can add the package to a basically sub-project, and because then GCC is not delivered, but it's not released, but it's used for building a package for

package hub, for example. You know, I was referring to like microcontroller development tools like Arduino and other stuff. Okay, so that means that basically the GCC version should be released and delivered to the customer, basically. That needs to be discussed, how we can do that.

So that's a good point, so we need to talk afterwards. Okay, there's another question. I understood how packages get in package hub, but sometimes packages change and leap in their structure, in the kind they are built, and is there any condition where they

can get out of package hub, where you lose them in package hub, or is it something we can rely on, if they exist there, that they are there to stay at least for some time frame?

That depends on the time frame. I mean, sure, the package will be staying in package hub unless there is a reason pulling this package. I mean, we had in the past, I think, twice or three times maximum the case where we had to pull the package, because also what is very important is to understand if there's,

for example, a security problem with that package, and no one is basically caring about that package, so the maintainer does not care, or if there is no maintainer anymore for that package, and it's too risky to deliver this package in package hub to customers or users, then this would be also a reason to pull the package.

But aside from that, there are not many reasons. Another reason can be, and that happened basically on the switch from SLE 12 to SLE 15, that some packages in SLE 12 package hub were moved basically to, for example, the workstation

extension for SLE 15. So the package was moved to a product. So this also can happen. It can also happen the other way around, that a package from SLE goes into package hub.

So it's bi-directional. Did I understand correctly that if a package has been submitted to package hub for a previous version of the SLE products, then you will take care and try whether it will also build

against the new product, or will that require a new submission from the community? What we are doing is basically taking all the packages, for example, which build in package hub SLE 12 and then moving them to SLE 15, package hub 15, and see if everything

builds. But what we are also doing is like syncing, this is something we did with the KDE Plasma 5 stuff, syncing these packages from LEAP so that we are basically on the same level. Are you using the staging for checking any submissions from the community?

Well, we are using the maintenance process. So that means every submission has first go through, usually, it's a policy. Every package has to be accepted in factory first. So that's the typical factory first policy. I was more referring to like, is there a chance that if someone submits a package update

into package hub that some other package might start to break? We had that in the past. That's what we know for factory, the staging repositories. We currently don't have any staging repository. But this is something we can also set up because we had this in the past that one

package update broke other packages. Any other questions? A suggestion. Story from practice, I've seen that the package hub is available in our subscription and have

a running a local SMT for mirroring all the SUSE repositories into our infrastructure. And I mean, nobody who has a reasonable size class installation will ever add package hub via the Yast module or something like that. And so you enable mirroring and then you try to add this package hub repository and

you see have you ever looked at the URL at the file name, at the directory name? Okay. You know what I'm getting at? I mean, I was not confident adding something in a subdirectory named slash 12 backports SP0 to my SP3 system.

So if the package hub I mean, the slash repository layout, slash 12 repository layout is quite crazy, but it's established since three service packs right now. And if the package hub could somehow blend in there so that it's maybe not delivered under products, updates, package hub 12 SP3, then I would know, okay, that's the package

hub repository for 12 SP3. Right now I really was not confident adding this to my slash 12 service and so I just put the package into my own build service and there are no. But that's a usability issue in my opinion.

Well, yeah, yeah, I know exactly what you're talking about. Okay. Everything is fine. Something to improve in the future probably. This is unfortunately, I mean, not unfortunately, but this is of historical reasons that how we decided to set it up for SLE 12. I mean, we set it currently up the same way for SLE 15, but we are currently also

in the process of, okay, maybe rethinking that in some extent. Because it might be also come in place when we are talking about the migrations from the LEAP systems so that we basically have the same or align more to the repo set up how

it is in LEAP, for example. Any other questions? Okay. Then thank you very much. You can get more information on packagehub.suze.com.

Thank you.