9

As is normal with Linux, distributions build their own KDE packages and distribute them through their own package management system. This has its good side, since it takes the burden off of the KDE team, but it also has its bad side in that the distributions tend to push early software, add their own artwork and software, and backport unstable changes in order to compete with the other distributions.

I do not think this should necessarily change. However, I think it would be good if there was an alternative. My idea is for KDE to release its own, totally vanilla packages for major distributions, with no distribution specific-change, no distribution-specific artwork, and no backported changes. Just the raw subversion repositories. Ideally there would be three, the current stable release, the current trunk, and, when available and different from trunk the betas and release candidates. This allows KDE developers to provide what they consider to be the true, core KDE experience, to properly break packages up by branches, stable, trunk, playground, kdereview, etc, and to facilitate testing without having to worry about problems created by distribution-specific changes, software, and backports.

Up until recently this would be infeasible. However, openSUSE Build Service allows you to pretty easily and automatically build packages for all popular distributions and all popular architectures (even ARM) and release those packages online for the distribution-specific package managers. The Linux Foundation, the group that is responsible for the Linux kernel, recently decided to use the openSUSE Build Service for their Linux Developer Network to allow developers to build their packages for all popular distributions simultaneously. I think it would be worthwhile for KDE to consider doing something similar.

TheBlackCat wrote:As is normal with Linux, distributions build their own KDE packages and distribute them through their own package management system. This has its good side, since it takes the burden off of the KDE team, but it also has its bad side in that the distributions tend to push early software, add their own artwork and software, and backport unstable changes in order to compete with the other distributions.

I do not think this should necessarily change. However, I think it would be good if there was an alternative. My idea is for KDE to release its own, totally vanilla packages for major distributions, with no distribution specific-change, no distribution-specific artwork, and no backported changes. Just the raw subversion repositories. Ideally there would be three, the current stable release, the current trunk, and, when available and different from trunk the betas and release candidates. This allows KDE developers to provide what they consider to be the true, core KDE experience, to properly break packages up by branches, stable, trunk, playground, kdereview, etc, and to facilitate testing without having to worry about problems created by distribution-specific changes, software, and backports.

Up until recently this would be infeasible. However, openSUSE Build Service allows you to pretty easily and automatically build packages for all popular distributions and all popular architectures (even ARM) and release those packages online for the distribution-specific package managers. The Linux Foundation, the group that is responsible for the Linux kernel, recently decided to use the openSUSE Build Service for their Linux Developer Network to allow developers to build their packages for all popular distributions simultaneously. I think it would be worthwhile for KDE to consider doing something similar.

Well it's also posible with Arch's ABS...
Or even emerge from Gentoo...
But I agree. at least as an otpin. And GHNS sould be "made" to be a package manager

Primoz wrote:Well it's also posible with Arch's ABS...
Or even emerge from Gentoo...
But I agree. at least as an otpin. And GHNS sould be "made" to be a package manager

Are those tools all able to build separate native package repositories (rpm or deb) for a bunch of versions of many different Linux distributions at once and automatically sign them and load them onto the correct servers? At least according to the Linux Foundation press release openSUSE Build Service is the only software that can do this:

The openSUSE® Build Service is the only development platform that enables developers to package software for all major Linux* distributions,

The Linux Foundation will be providing an interface to the openSUSE Build Service via the Linux Developer Network site, so that developers can create packages for all major Linux distributions via LDN. The build service enables developers to create packages for CentOS*, Debian*, Fedora*, Mandriva*, Red Hat* Enterprise Linux and Ubuntu*, in addition to openSUSE and SUSE® Linux Enterprise.

Primoz wrote:And GHNS sould be "made" to be a package manager

KDE-apps and similar sites could probably also be set up to use Build Service to build packages and upload them to the correct repositories.

TheBlackCat wrote:Are those tools all able to build separate native package repositories (rpm or deb) for a bunch of versions of many different Linux distributions at once and automatically sign them and load them onto the correct servers? At least according to the Linux Foundation press release openSUSE Build Service is the only software that can do this:

The openSUSE® Build Service is the only development platform that enables developers to package software for all major Linux* distributions,

The Linux Foundation will be providing an interface to the openSUSE Build Service via the Linux Developer Network site, so that developers can create packages for all major Linux distributions via LDN. The build service enables developers to create packages for CentOS*, Debian*, Fedora*, Mandriva*, Red Hat* Enterprise Linux and Ubuntu*, in addition to openSUSE and SUSE® Linux Enterprise.

Wow I had no idea, that that was posible with SuSEs packager, emerge is AFAIK "just" an source compiler, and Arch ABS is an Arch package builder.
But still SuSE supports "only" deb and rpm packages and no others.

And I don't agree that the packages distributed like this should be packaged in .deb or .rpm packages, thy should use pkg.tar or similar format a distro independant, so it's trully "platform" independant.
Idealy this packages would be packaged in such manner that could be installed on Windows and OS X.
But that's tekaing this idea to extreme.
But I still agree that it it would be really cool, if nothing else, if KDE would have a svn GUI so you could compile and install packages on your own as sometimes Distro packages don't provide everything.

I know that I have a problem installing Karbon or any KOffice2mod packages because thre's a dependacy missing and I don't need the whole suite provided by
Arch repo, I would much rather use more modular Chakra (KDEmod) repo packages where you can install one KOffice app only.

Primoz wrote:But still SuSE supports "only" deb and rpm packages and no others.

So far. Build service is still a work in progress.

Primoz wrote:And I don't agree that the packages distributed like this should be packaged in .deb or .rpm packages, thy should use pkg.tar or similar format a distro independant, so it's trully "platform" independant.

Ordinary users are not going to want to compile KDE from source every time there is an update. The whole point is to provide repositories that just work. Users just have to add the official KDE repository for their own distribution and they will have access to official vanilla KDE packages as easily as they install their distribution's own software. It is infeasible for KDE to do this by hand for every version and every architecture of every distribution, but with a single program that handles it all mostly automatically for most distributions I think it is worthwhile. Of course people will still be able to compile from source, but requiring people to do so is unrealistic, especially if you want KDE to reach a broader audience.

Primoz wrote:I know that I have a problem installing Karbon or any KOffice2mod packages because thre's a dependacy missing and I don't need the whole suite provided by
Arch repo, I would much rather use more modular Chakra (KDEmod) repo packages where you can install one KOffice app only.

This idea is not aimed at the sort of person who uses Arch, i.e. people who want to compile everything from source, it is aimed at everyday users that want things to work with little hassle and minimal oversight on their part, but still want to have a pure, unmodified KDE experience. This is currently impossible on most distributions.

+1 for this

Yeah! +1

Fantastic idea +1!

I disagree with this as the developer time will be wasted on build service rather than the program development. -1

Why do you think so?
The KDE-team would have to create some configuration-files for the build-service.
The build-service-enhancement are done by the build-service-team.

disagree - this is what distributions do and I'd rather have KDE focus on development than preparing and maintaining packages.

And for which distributions (how do you determine major)? And which versions of the distro (as most still support various releases)? And which architectures (386,486,586,686,ppc and/or 64bit)? And who will do testing on each distro/release/arch/kde-version to insure that it works with the particular base distribution?

google01103 wrote:disagree - this is what distributions do and I'd rather have KDE focus on development than preparing and maintaining packages.

The whole point is that distributions do NOT do this, they release their own, highly modified version. Besides, build service handles most things automatically, it won't take much work.

google01103 wrote:And for which distributions (how do you determine major)? And which versions of the distro (as most still support various releases)? And which architectures (386,486,586,686,ppc and/or 64bit)?

Just do whatever build service supports. The whole point is that build service automates all of this. The KDE developers will not have to worry about it. They just submit the source files and packages are built for everything build service supports. As build service is improved to support additional distributions, additional version, and additional architectures the KDE packages will become available automatically.

google01103 wrote:And who will do testing on each distro/release/arch/kde-version to insure that it works with the particular base distribution?

Who is testing the source code to make sure that if it is compiled by hand it works on every distribution? Whatever they do for the source code would also be done for this. Nothing more, nothing less.

TheBlackCat wrote:

google01103 wrote:disagree - this is what distributions do and I'd rather have KDE focus on development than preparing and maintaining packages.

The whole point is that distributions do NOT do this, they release their own, highly modified version. Besides, build service handles most things automatically, it won't take much work.

The build service, as its name says, just builds, nothing more.

TheBlackCat wrote:

google01103 wrote:And for which distributions (how do you determine major)? And which versions of the distro (as most still support various releases)? And which architectures (386,486,586,686,ppc and/or 64bit)?

Just do whatever build service supports.

And if somebody wants packages for a distro which is not handled by the build service? This would be unfair for them, and for sure not something KDE would do.

TheBlackCat wrote:

google01103 wrote:And who will do testing on each distro/release/arch/kde-version to insure that it works with the particular base distribution?

The KDE packaging teams of the various distro.

TheBlackCat wrote:Who is testing the source code to make sure that if it is compiled by hand it works on every distribution?

You are ignoring google01103's question, which is *not* the same of the counter-question you proposed. Everybody, either who compiles KDE from sources and also the distro packages, can test KDE compiles on their system.
Although, compiling KDE by hand does not guarantee you that fits and integrate in the distro. This why sometimes distros have to do changes to KDE; one of the examples of that could be the layout of the main (K) menu.

I think you are simply underestimating the effort needed for providing a package.

The time and the resources needed for the actual build time of a package are just bits in the packaging process. What is there are steps like: writing the real packaging structure, making sure it is coherent, does not give conflicts with other distro stuff, keeping it updated, and so on.
Packaging is lot more than a "5 minutes work, then feed the build service". It drags time, a lot of time and resources, which distros already spend to try to provide you working packages. You can imagine yourself: if the teams that package KDE on the various distro spend much time in provide packages, then the same would be needed when doing "vanilla" packages, no more and no less.

One of the bottom line is: if you think the KDE packages of your distro suck, then you either report them, change distro or compile KDE yourself.
But, working around "bad packages" like you would suggest for sure would not help distros at all.

pinotree wrote:The build service, as its name says, just builds, nothing more.

No, it builds a bunch of times, tests the build for basic errors, then uploads it to a server. It also automatically rebuilds packages when there is a change, including all packages that depended on that package.

pinotree wrote:And if somebody wants packages for a distro which is not handled by the build service? This would be unfair for them, and for sure not something KDE would do.

The Linux foundation did. Are you saying they are being unfair? Packagekit currently does not support the package managements systems used by all distros. Is KDE being unfair by supporting it? This may not be an optimal solution, but it is better than nothing.

TheBlackCat wrote:You are ignoring google01103's question, which is *not* the same of the counter-question you proposed. Everybody, either who compiles KDE from sources and also the distro packages, can test KDE compiles on their system.

Then they can test the built packages as well. My point is that KDE should offer the same level of support for the built packages as they do for the source tarballs. Nothing more, nothing less. And users should expect that. Lots of distros have totally unsupported but still official repositories.

pinotree wrote:Although, compiling KDE by hand does not guarantee you that fits and integrate in the distro. This why sometimes distros have to do changes to KDE; one of the examples of that could be the layout of the main (K) menu.

The whole point is to NOT have it fit into the distro.

pinotree wrote:I think you are simply underestimating the effort needed for providing a package.

Perhaps. This is brainstorming after all.

pinotree wrote:The time and the resources needed for the actual build time of a package are just bits in the packaging process. What is there are steps like: writing the real packaging structure, making sure it is coherent, does not give conflicts with other distro stuff, keeping it updated, and so on.

Once the build structure is set, I was under the impression build service would handle any future changes. And of course it would conflict with the distro's own software, you wouldn't have both at the same time. A distro's own, say trunk version of KDE will conflict with its version of stable KDE as well. There is nothing surprising there.

pinotree wrote:Packaging is lot more than a "5 minutes work, then feed the build service". It drags time, a lot of time and resources, which distros already spend to try to provide you working packages. You can imagine yourself: if the teams that package KDE on the various distro spend much time in provide packages, then the same would be needed when doing "vanilla" packages, no more and no less.

It would certainly be less, because as you said the distros also make a lot of distro-specific changes as well, spend a lot of time backporting things, and spend a lot of time integrating it with their software, none of which the KDE people would do. How much less I don't know, but it would certainly be less. Based on my understanding of the build service, it might take a fair amount of work up-front to get everything set up, but once it is then it should be fairly automated.

pinotree wrote:One of the bottom line is: if you think the KDE packages of your distro suck, then you either report them, change distro or compile KDE yourself.
But, working around "bad packages" like you would suggest for sure would not help distros at all.

I don't think they suck, but Aaron Seigo says over and over again how he thinks the distros' constant attempts to outdo each other by constantly pushing unstable and unfinished changes are hurting linux and hurting KDE particularly. This was an attempted solution to his issue. This is not an attempt to help distros, it is an attempt to help users.

++++++