Situation
On Fedora, there are basically four repositories:
- Stable - end user product
- Testing - stabilisation tree
- Rawhide - development tree (our factory)
- Kopers - personal repositories (bit like our Build Service home projects)
As you might know, Fedora Stable does currently receive quite some package updates over it's lifecycle - catering to users who want the latest software. The downside of this is that it sacrifices stability - you can't have your cake and eat it too. And for some users - even that isn't enough. They want the latest Banshee when it is released right away - not wait for it to mature in Testing. So they have to enable Rawhide repositories - often bringing in far more unstable software than just Banshee or whatever they're after. And that software is build against a whole different stack - Rawhide has moved beyond stable of course, adding things like a newer glib or other base libraries and building against a newer GCC. All this creates a significant risk for instability.
Solution?
Máirín describes 4 target users of Fedora:
- Caroline Casual-User
- Pamela Packager
- Connie Community
- Nancy Ninja
She proposes to give each of these users what they want by essentially splitting the update policy for packages based on what 'level' the are. She recognizes Core Platform, Core Desktop and Applications. Core Platform should only receive crucial fixes and security updates, Core Desktop should get a bit more liberal updates and Applications should always be up to date. This way, users won't get bitten by instability, yet those who want more up-to-date software don't have to resort to Rawhide either.
Does this solve the problem? It does if you assume these more up-to-date packages for the Applications don't ever break things for Caroline. And if you assume that there is no reason why Nancy Ninja newer version of something in the Core Platform or the Core Desktop for the app she's writing.
openSUSE
openSUSE is far more conservative when it comes to upgrading packages in the stable release. Making it a much more stable platform. So, that means you're always a bit behind and you can't have the latest and greatest? No! openSUSE users CAN have their cake and eat it too. Thanks to the Build Service, newer versions of enduser applications and libraries can be entirely build against the stable distribution, lowering the number of packages you need to pull in and thus increasing stability.
Máirín and the other Fedora peeps don't use OBS - luckily, it's a Free service. Sponsored by Novell, AMD, IP Exchange and B1 Systems. Many packages on the openSUSE buildservice are build for various stable Fedora releases as well as for Red Hat releases, Ubuntu, Mandriva and of course SUSE Linux Enterprise. And the Build Service is also used by third parties like MeeGo to build their packages in house.
So I would invite Fedora users like Caroline to grab just the one package she needs from OBS!
For developers - and users
So the buildservice is awesome for developers who want to make their software available to users - no matter what distribution they use. The Build Service builds each package on a clean virtual machine install of the target distribution, guaranteeing compatibility. Check the documentation here. And a nice tutorial here. Note that it currently mostly focusses on the commandline solution OSC - but you can actually build and packages entirely from your webbrowser and get them to your users with almost no hassle using the gtk-apps.org and kde-apps.org OBS integration. Be like Lucky Backup and offer packages for ALL mayor distro's instead of only Ubuntu OR Fedora Or ...!
And for openSUSE and it's users, OBS enables us to cater a much wider audience than we ever could without. We can make newer software easily available for users who want it thanks to the one-click-install; yet users who want stability can have it. Surely there is still work to do - a proper app-store would be nice, although the search on software.opensuse.org IS pretty good...
Of course there is more awesomeness to openSUSE - like SUSE Studio (cool video here) and more. I just wanted to highlight one thing ;-)
In my experience, from the time I still used opensuse, about three monthes ago, the problem with the OBS is that it is an excellent idea on paper, like you described it, but the implementation and the reality is very different, and it is very bad from an user point of view. First of all, from a user point of view, there are two differents UI, one to install "official-stable" package, and the other one to search in the OBS (search that often fails while the website finds match...). What could be an improvement is to have a single UI, with an option, disabled by default, to look for newer version in the OBS and offer them when the user is looking for an application. Second problem is that there is often several repositories that offer the same version of an application, it is difficult to choose which one you really want, so in the end you pick "factory" and like for Fedora you get update to other things that can break your system, or you pick something from a "home" repository, and there you are lucky if it install, sometime you need to enable some other repositories, and run.
ReplyDeleteI like the idea of the OBS, but at the end of the day, you have to realize that maybe it was not a good solution. And that having either semi-official updates, or a stable and testing repository is not so bad. And I don't know how it works in Fedora, but now, for my new computer I have moved back to debian, using testing as a stable repository, and pulling from unstable/experimental when I need or want newer version, and I get less problems than with the OBS since I get package that have more quality control, since they are meant to be part of stable, than most things that you find in OBS outside "factory".
Well, I said we need a better solution for getting at OBS packages than what we have now, that's surely true.
ReplyDeleteThe Debian solution means mixing unstable and testing. It often works for a while but not in the long run. It is very annoying during the huge freeze periods needed to churn out a new stable release. And it can completely break if unstable suddenly makes you pull in a lot of stuff and you can't boot anymore... Or you get weird segfaults or other breakage. OBS doesn't have that as packages are build for your specific openSUSE/Fedora/etc version.
Sure, you can work with pinning and priorities for packages and if you like to figure that all out than it can work reasonably well. But once you're at that point it has probably been more complicated and more work than openSUSE with it's OBS - and we've got a solution which needs 'just' UI changes, not a fundamental rebuild :D
Jos,
ReplyDeleteMáirín's post was brilliant. This is my personal opinion, but I already know who Fedora aims for. If you are not aware of this information, it might be tricky to understand at least Caroline. Caroline is mainly why I consider the post brilliant, but moving ahead...
In a way, I find this like walking through a minefield... You can't please everyone and Máiríns article was good at showing that...
From a very simple way we could straighten things up like this:
Positioning > What makes you (or your solution) special. Evaluated as, do your $USER's see it that way? If not, work it out.
You can do better than Fedora by doing one thing different:
* There is no openSUSE Linux
* There is no openSUSE Community
Which leads into: THERE IS OPENSUSE! openSUSE is a whole, it contemplates the community and the linux service. This will help you out straighten the whole process of positioning correctly and working it as a marketing service.
You can choose to keep a differentiation between Linux and Community and you will end up with more work around pretty much everything. Fedora has something nice: "YOU ARE FEDORA", it's common on the community but on the field, not everyone is Fedora, which is a flaw they should work out.
Another cool advice to help, would be to start also promoting people and projects and not only features. But this is just my interpretation based on a difference concept of service marketing which is fairly easy to understand, maybe one day we can talk about it.
I believe that if work and commitment is placed in showing openSUSE with just one face which translated either service and community (and the community is by far the most important part of any service, followed by a time frame window you can't ignore) it will be easier to define and work on what we call Marketing Management, which is pretty much a set of tools that might help you:
1. Analysis/Auditing > Where are we (openSUSE)?
2. Objectives > Where do we want to go?
3. Strategies > The best way to get there?
4. Tactics > How do we get there (this is mainly what gives marketing such a bad name, the tactics used and strangely people associate Marketing with Promotion, which has a strong presence here, but not in most of the process).
5. Implementation > Getting there!
6. Control > Assure a good arrival!
This could be metaphored with 'life cycle for Marketing'. I hope that this steps (which were taken from my presentation for the openSUSE Conference) are a guidance for what you have ahead.
What others do, might not be the best for us, specially if we have different positioning and if we have different audiences.
I leave you a quote that I hope you can find a meaning for it, because it does have a strong meaning for me:
"Management by objective works - if you know the objectives. Ninety percent of the time you don't." - Drucker
The reason why I quote this is because I do have problems also finding the objectives ;)
Hi, Jos! Very nice post!
ReplyDeleteYou wrote about update policies of Core Platform, Core Desktop and Applications. They must be different, that's right. For example, the initial release of openSUSE comes with KDE 4.4.4. Today we have bugfix release KDE 4.4.5 and completely new KDE 4.5.1. I can update KDE 4.4.4 to 4.5.1 from Factory if I want, but how can I update KDE 4.4.4 to 4.4.5? This is a bugfix release of Core Desktop, isn't it? Why it is not in main repositories? Why I can find Amarok 2.3.1 in KDE UpdatedApps repository but I can't find KDE 4.4.5 in KDE Core repository for 11.3? I don't want completely new desktop from Factory (because of stability) but I want the lates bugfix release of base desktop version (and again because of stability)!
Hi Jos,
ReplyDeletenice to read your post but I think we have to start to thinking different, from a user's point of view subscribing a repo is a unmeaningful task, "I installed openSuse, why i need to waste my time with this repos?"
So we need a nice way to let users to obtain software updates without subscribing to any repo. The update applet should provide security fixes and software updates. The latests need to be rendered with some type of rating about their stability.
Stability = 1 -> "Warning installing this software will break your system"
The package manager should provide a easy way to revert to the stable release.
My 2 cents.
Having a build service isn't the problem. Fedora has one too, we just don't yell about it as much. =) It's called Koji, and it works perfectly well. Any developer can kick off a build of any spec for any release; it's trivial to, say, do an F13 build of the F14 or Rawhide spec for a package. If that were the only problem there wouldn't *be* a problem. Just doing a build isn't enough, though. The real issue is with providing a reliable defined source of the 'types' of updates different users want. You don't really just want a single build of a package at a single time; at the least, you want all the later updates of the same type for that package too. And often just that package isn't enough; it depends on other packages which also need updating. (After all, this is why distributions exist at all).
ReplyDeleteA build service is a necessary prerequisite, of course, and the OBS is a perfectly good one. But it isn't a solution to this question.
And to add some comments on what adam said, at Mandriva, we have 4 types of repositories ( in fact more than 4, with variations like core ( called main ), non-free, etc ) : Release, do not change after release. Updates, for bugfixs and security fixes, minimal change only. Testing, for testing fixes before they go in Updates ( for QA, and for bug reporter ). And Backports, for backport of "leaf" packages, ie package that nothing requires.
ReplyDeleteYet, people are not satisfied, because the policy is too complex for most users, and the appreciation of going to bugfix or backport cannot be fully infered from version, thus cannot be check by script, and so errors can happen. And of course, there is people that want backport of very central packages ( kde being one ) that should not be backported without lots of test.
We also let the choice to people, but once there is a problem with a backported rpm, helper on forum tend to say "you should not have use it", and so backport get a bad reputation ( like ppa on ubuntu, where people tell "do not use them, this will break upgrade" ).
Not to mention that having different version of everything can make life of packager and support people much harder. So trying to get everybody happy usually mean that packagers have more work, and that whatever you do, people will get lost, and some users will still be unhappy.
( and by the way, like opensuse, and fedora, and most distribution, we have a build system that make backport easy ).
So, personnally, I think users must realize that the time packagers use to backport a rpm is time they do not spend on making next version better. So backporting rpm is not really "free" whatever you do, in term of ressources.
I agree with Cyrille. OBS empowered packagers and contributors, but from a user perspective it did not improve anything with respect to the past, and I think in part contributed to make the user experience worse.
ReplyDeleteSuSE (with the small u) used to have a couple of unofficial repositories (Packman and Guru) for key applications, codecs and such. And then some additional repository for more experienced people, with new kernels, samba and so on.
If you wanted to be safe, you knew what to do. You simply did not use anything but the standard repositories and updates, and take from packman and guru the minimum possible. It used to be a good way to have a stable system, for the whole release life.
Today openSUSE formally has three official repositories (OSS, non-OSS, update), and it still has packman, since guru merged with it. So someone might think: well, where is the problem?
I think the problem consists mainly of two aspects:
1) openSUSE and SuSE have different levels of quality. SuSE used to be a distribution you installed and forgot, openSUSE is still a nice distribution in most cases, but it is quite often released in a condition that requires users to install unsupported key components (the last release is a perfect example, since it comes from a quite troublesome kernel, in spite of patches). So, basically, if you apply the "old rule" of only using official repositories, you might have problems, and the suggested solution is to use unsupported (meaning from non-standard repositories) packages, with the result of exposing users to additional risk.
2) OBS does not provide any rating of packages, it mixes repositories, it is full of duplicates, and it is unclear what package can be considered reasonably reliable, also thanks to the quite confusing and technical naming convention of various repositories (GNOME and KDE are masters in this :-)), the excessive split of public repositories in sub-repositories and so on.
Thanks for the comments ;-)
ReplyDeleteI think the biggest issue with OBS is not the principle of it - eg Adam said you might need newer versions of other software too if you want a new version of a package. Well, OBS takes care of that too, rebuilding what is needed.
And indeed, for packagers, OBS is great. The problem is how it is presented to users. As Alberto said, no rating, duplicates, confusing naming etc. Recently there was a big rename of some central repo's to clear things up, and OBS is also integrated to some extend in Yast - but there surely is still a lot of work to do. Still I think OBS IS the solution to 'having your cake and eat it too'.
If it had some better GUI we'd get pretty far and could focus more on the core being fully stable - again as Alberto said. By picking the right repositories (and a good GUI can/should make that easy) you can have a solution close enough to what Denni and Anonymous mentioned - you pick the 'level of stability' that you want, either per package or per group of packages, and you have what you want.
Nice Article.
ReplyDeleteIt's good to understand how openSUSE works and how it relates to another distros.
I still don't really understand something about OBS: Is it any good for Joe Dumbface (i.e. me) who doesn't know how to put packages together or doesn't want to use his bandwidth downloading a ton of dev packages to his local machine to get a package to compile?
ReplyDeleteI have always envisioned an online service that lets users point it to a source tarball on the internet and have the build service figure out which build deps it needs and automatically creates binary packages. Is this possible with OBS without manually preparing the package structure or researching all the dependancies needed for the package to compile?
Angkleface: That is *exactly* what the buildservice is for, yes. You upload (the location of) a tarball and spec files it can build the package. The spec files are of course the issue - but the KDE-OBS-Generator (silly name, nothing KDE about it) can do that for you provided you have the tarball on your disk. If that tool gets integrated in OBS (hopefully soon) it'll be even easier.
ReplyDeleteWhich would then be exactly like you describe.