Mailinglist Archive: opensuse-factory (723 mails)

< Previous Next >
Re: [opensuse-factory] updating factory
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Fri, 31 Mar 2006 12:19:32 +0200
  • Message-id: <442D0234.6080308@xxxxxxxxx>
jdd wrote:
Pascal Bleser wrote:

Doing it the proper way is a pain in yast2 btw: select categories, go to
"zzz", and choose "update all" (or something like that). That's not very

I don't know if it's really the same discussion... I can
open a new thread if you think so :-)
but there are always problem defining what all this mean.
I was said recently that it was no more usefull to make
bugreports about 10.0 if not security ones.
so it's not clear to me of what exactly YOU, update and
upgrade do.

- YOU: online updates: packages provided by SUSE to fix security issues and sometimes severe bug fixes. No feature upgrades, only for security fixes.
- update: well... that's what is kind of missing in yast2 (to do it, it's like I described in my previous mail). It's just when you want to have the latest available version of some or all packages that are installed on your system.
- upgrade: upgrade the whole distribution, e.g. from 10.0 to 10.1

specially seeing that SUSE packages are always way behind
the ones found on the devs web site.
it's not a complain at all, it's not possible to follow each
and any package, but a clarification is always good.

I think this has been discussed at least a dozen times, but...

You don't want to have the latest version of everything. Really, you don't. And even if you think you want that, you don't.

Novell releases versions of SUSE Linux, that are kind of snapshots of one version of every single package that is shipped within the distribution.
Those packages are tested, both by the SUSE QA team and by beta-testers (that's us). That means that, for example, SUSE Linux 10.0 is a consistent, well tested set of packages that all have a certain version.

Now, if you had a distribution that was permanently "moving" because it would always provide the latest version of every single package it includes, you would:
- have issues with repositories and infrastructure, as we already see with factory: it's not synced everywhere because it changes every day, metadata for several thousands of packages has to be generated again and again
- have a very, very unstable system because there is no time nor manpower available to constantly test every single release of every single package that's in the distribution
- have a very, very unstable system because problems don't only happen inside the scope of a single package, but also between interactions of different packages (e.g. the kernel and X-Window DRI drivers, the GTK2 version and GIMP, etc...), which means that in theory, you would need to test a large part of the distribution (e.g. every single application that uses GTK2 or GNOME if you upgrade the gtk2 package) with every single package update

Do you really want that ? I don't think so ;)

If you want the latest version of some application or library, use 3rd party repositories like Packman, James Ogley's, mine, or one of the many suser-* repositories hosted on

Those packages are mostly *not* tested, except by the users themselves.

We usually only package leafs of the dependency graph. I mean, end-user applications like kaffeine, k3b, gimp, stuff like that.
Libraries (that, by their very nature, can affect a lot of applications when they have bugs or incompatibilities) are less frequent in our repositories.

*what are the packages patched by SUSE? these ones should be

YOU provides patched packages for every single package that
a) is part of the SUSE Linux distribution
b) has a security flaw fixed by the patch

Also note that, as long as it is technically feasible, the SUSE packagers don't provide new versions of a package when it has a security issue. They rather backport the patch that fixes the problem to the version that is currently shipped with the distribution.

For example, in SUSE 10.0 you have the following kernel package:

Now, imagine there's a security flaw in that package, that is fixed by the kernel developers in 2.6.14 or 2.6.15

Well, to avoid introducing a lot of side-effects and a lot of code changes, the SUSE kernel packagers will backport the patch that fixes the security flaw that was made by the kernel devs in 2.6.15 to the 2.6.13-15 codebase. YOU will then ship a kernel-default-

taken from SUSE repositories to keep in sync with the
distro. I beg these ones are updated by YOU? may be there
are several kind of patches (enhancement, distribution
adaptation, security?).

Only security, no feature enhancements.
I hope the reasons are understood, from what I wrote above ;)

To summarize: the more changes, the more risks that things break.

*what packages are changed by an update?

Those that you select when you say that you want to update them.

*what packages are changed by an upgrade?

When you do a distribution upgrade ? (what is named "system update" in yast2)
The 10.0 packages will be replaced by the packages shipped on 10.1.

I think that initially the page was said to
give this: what is different from the previous version.
I now don't give this info.

s/give/have/ ?

I think that will be available when 10.1 is released.

Probably it should be worth to have a list of all the
packages ever used in SUSE (raw) with a quotation mark in
the distro number (column-or better the version number).

You gotta be kidding. Why don't you do it yourself ?

But this needs any kind of sorting, because there are a
great many :-)

$ zgrep 'src.rpm$' INDEX.gz | wc -l

$ zgrep -E '\.(i586|i686|noarch)\.rpm$' INDEX.gz | wc -l

may be it could be worth a database app with entried for
packages, versions (initial, last updated), SUSE versions.
but I don't know how to integrate this in the wiki (by the
way don't Novell/Suse have already such data???)

That can be done from the INDEX.gz file that's on every SUSE Linux CD, it has a list of all packages (of all files on the media, actually).
At least that can be used to compare versions from one SUSE Linux release to another. It doesn't track the Online Updates, obviously.

You don't really want to have a "database" on a wiki page that lists almost 6000 items, don't you ? ;)

And anyway, how would that be useful to anyone ?
Why would you want to have that information ?

-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels

< Previous Next >
Follow Ups