Blocker? They should provide some more locales, but they should not exist for every single language. These bundles are for the CD only and technically they should not exist in anything but english. And yes, this means german users would need to download all the -lang packages. But I doubt creating 300 packages is a solution.

> These bundles are for the CD only

No, they are and should be on the DVDs as we (without Coolo) discussed today.

*** Bug 302300 has been marked as a duplicate of this bug. ***

make sure to change the maintainer before you change the way the package is meant

These bundle packages are completly impracticable for any kind of factory or build service user. Whatever you discussed - you were wrong.

I see you removed all the lang packages from factory too - basically making it impossible to do a version update of just k3b from build service later.

Problem: atk-1.19.6-8.i586[factory] cannot be installed due to missing dependencies
Problem: gail-1.19.6-10.i586[factory] cannot be installed due to missing dependencies
Problem: gconf2-2.19.1-15.i586[factory] cannot be installed due to missing dependencies
Problem: gimp-2.2.17-15.i586[factory] cannot be installed due to missing dependencies
Problem: glib2-2.13.7-11.i586[factory] cannot be installed due to missing dependencies
Problem: Can't satisfy requirement libgmime-2.0.so.2 for gmime-2.2.10-11.i586[factory]
Problem: gnome-vfs2-2.19.3-10.i586[factory] cannot be installed due to missing dependencies
Problem: gstreamer010-0.10.13-22.i586[factory] cannot be installed due to missing dependencies
Problem: gtk2-2.11.6-13.i586[factory] cannot be installed due to missing dependencies
Problem: libbonobo-2.19.6-8.i586[factory] cannot be installed due to missing dependencies
Problem: libbonoboui-2.19.6-11.i586[factory] cannot be installed due to missing dependencies
Problem: libgmime-2_0-2-2.2.10-11.i586[factory] cannot be installed due to missing dependencies
Problem: libgnome-2.19.1-10.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomecanvas-2.19.1-9.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomecups-0.2.2-109.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomeprint-2.18.0-40.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomeprintui-2.18.0-46.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomesu-1.0.0-137.i586[factory] cannot be installed due to missing dependencies
Problem: libgnomeui-2.19.1-10.i586[factory] cannot be installed due to missing dependencies
Problem: libgtksourceview-2_0-0-1.90.3-9.i586[factory] cannot be installed due to missing dependencies

Problem: atk-1.19.6-8.i586[factory] cannot be installed due to missing dependencies
 There are no installable providers of atk-lang == 1.19.6 for atk-1.19.6-8.i586[factory]

atk-1.19.6-8.i586[factory]
==========================

atk-1.19.6-8.i586[factory] will be installed by the user.
atk-1.19.6-8.i586[factory] is needed by atk-devel-1.19.6-8.i586[factory] (atk == 1.19.6-8)

 Solution 1: do not install atk
  do not install atk-1.19.6-8.i586[factory]
 Solution 2: Ignore this requirement just here

Christoph, please drive this bug.

How it should be:

bundle-langs are just a workaround for the space limits of thinclient installations and were abused for the same space limits of our CDs. They are _not_ a general solution.

So we put the bundles on CD to satisfy the english translation needs of a very specific version set. We don't put them on DVDs as the -lang packages are more flexible and are easier to update from build service projects and have many more advantages.

Yes, that makes the CDs incompatible with the DVD. And if you register a build service project to the CD, which has a newer k3b version, you'll get a conflict over k3b-lang, which will result in the removal of the bundles and the download  of the other lang packages from the FTP tree.

This was a known drawback when this was designed, but wanted this way. Because otherwise we wouldn't have been able to provide CDs at all. And we won't create workarounds for workarounds now. I find the solution very much acceptable for 10.3 and we should discuss a perfect solution after 10.3.

So revert whatever you did to pre-beta2. Right now registerig a build service project is completly unsolvable.

One more thought: the lang packages should be on the lang addon CD

ok, thats how I understood it as well. this basically means: 

- no bundle-lang-common
- put the -lang packages on ftp/dvd tree again

and all the issues will be solved. the only thing missing is yast not popping up a conflict dialog when the bundle-lang transition is happening, but thats just a minor issue (as there is only ONE conflict and not x conflicts for bundle-lang-gnome,bundle-lang-kde and bundle-lang-common like it is now), and we could live with it for 10.3 even. 

A situation without bundle-lang-common is unacceptable, since users will face conflicting packages as soon as they add an online repository or try to install both desktops in parallel. AJ was facing this problem already when we were preparing for Beta2.

In our discussion (yesterday), we thought about having a fall-back path, where bundle-lang-* would store it's files and remove all conflicts of *-lang packages, which would then store their (potentially identical files) in the default locations, which overrides the fall-back.

How about that?

you can't install both desktops in parallel when installing from CD. This problem might be a follow up of the decision to put the bundle langs on DVD. So what you name unacceptable is just not supported.

I don't care if there is a lang-common, it shouldn't make things worse. But implementing fallback paths is way too invasive and nothing you do for a minor issue after beta2.

> that makes the CDs incompatible with the DVD. [..] you'll get a conflict [..] will result in the removal and download 

This all sounds horrible! :-( 

> Because otherwise we wouldn't have been able to provide CDs at all.

What happened to the KISS approach actually? AFAIK the goal is to have single CDs with English flavor only (and we don't have the goal to save DVD9 space by making more stuff noarch here).

So let us have a %find_i18n macro which splits the non-English parts into an app-i18n sub-package, which provides locale(app:xxx) entries for its content, while keeping the English parts in the main package.

How would this solution not allow us to provide single CDs? Where would it cause problems (no strange provides/requires/conflicts)?



PS: Feel free to s/i18n/lang/ above, just wrote it for clarity. :-)

This has several drawbacks. The main one would be that the lang splits weren't done for the CDs, but for thin client installations and there customers want not just english but english+danish or english+german and then your solution would be screwed.

But we can continue discussing in that direction after 10.3 I guess, but perhaps someone finds an even better solution to the problem. Unfortunately it's not a trivial problem.

As we don't have Danish bundle packages I guess those thin client products would be built from new RPM specifications anyway so I strongly suggest to go with my proposal to solve the problem for the one CD openSUSE 10.3 media.

Use the best solution for every problem and don't try to "abuse" as you said the one solution for some other problem.

Alright, after a lengthy discussion we have worked out a plan to actually improve this situation. Here is what we are going to do now:

1.) introduce /usr/share/locale-bundle/ -- a fallback path where all bundle-lang* packages will store their files. (To be able to install bundle-lang* packages and <package>-lang packages side by side, which will happen especially with online update and the openSUSE Build Service.)

[a little special case that popped up after the discussion still needs to be addressed -- but that's something for post Beta3 ;) Beineri has the details.]

2.) Change bundle-lang* to store their files in /usr/share/locale-bundle/

3.) Split out more languages from bundle-lang-*. Let's first go for Novell Tier 1 and Tier 2 languages:

  * English
  * Portuguese (Brazil)
  * French
  * Spanish (Mid-Atlantic)
  * German
  * Chinese (Simpl.)
  * Chinese (Trad.)
  * Japanese

  * Russian
  * Czech
  * Hungarian
  * Polish
  * Korean
  * Finnish
  * Danish
  * Norwegian
  * Swedish
  * Dutch

3.) introduce dummy package bundle-lang-other, to provide all locale(...), which we don't have as bundle-lang-*-<lang>. This package should obsolte bundle-lang-*-* (how to handle this?).

This package should own all locale dirs inside /usr/share/locale-bundle/!

4.) have all <package>-lang package supplement bundle-lang-other, so we can pull them in, in case a language that's not supported by bundles is being selected.

5.) remove Conflicts from -lang packages to bundle-lang-*

6.) make sure to only have the -lang packages inside the FTP tree, the DVD9 (retail) and potentially the addon lang CDs.

6.1) download DVD (which will only support a limited set of langs) and 1CDs will only ship bundles

That's hopefully all. Dirk, Beineri, did I miss anything? :)

1) I guess the "special cases" are the prefixes /usr/share/gnome/help/, /opt/kde3/share/doc/HTML/ and /opt/kde3/share/locale/ which also appear in the bundle-lang packages and require each to have a separate place to patched.

3) > This package should own all locale dirs inside /usr/share/locale-bundle/

That's wrong (but is correct on the board), bundle-lang-common should own the directories.

another problem is that the bundle-lang-other supplements will a KDE user actually cause to download all GNOME CD -lang packages, even if the main package is not installed. I think thats a regression from the 10.2 situation. 

one solution would be the packageand() supplement, e.g. amarok-lang would

Supplements: packageand(bundle-lang-other:amarok)

however, that means this is unversioned, and will cause headaches on a distro upgrade. 

Klaus, is the version on packageand() resolvables defined? is it checking the version of the first or the second parameter?

if the versioning is defined, then

Supplements: packageand(bundle-lang-other:amarok) = 10.3

would fix it. 

Dirk, very good point! Wouldn't it be sufficient to use packageand() and require a specific openSUSE-release package in addition to that?

And you found all places to add these bundle fallback paths (e.g. in glibc)? Or do we only care for english anyway?

packageand() is implemented and translated to a freshens/supplements combination internally. So combination with other dependencies using the same approach (like 'locale()') must be taken into account.
Multiple freshens and multiple supplements are 'OR'ed.

It is _not_ possible to specify a version for 'packageand()', only package names are allowed. (see # 255011 for details).

comment #18: Christoph, please put this stuff into a wiki. Bugzilla is rather bad as a documentation tool ...

Submitted adapted kdelibs3 package:

+Mon Sep  3 15:08:18 CEST 2007 - stbinner@suse.de
+
+- search for locale and help also in /opt/kde3/share/locale-bundle,
+  /opt/kde3/share/doc-bundle & /usr/share/gnome/help-bundle (#302270)

Hmm, #18 misses italian ?

I have no idea where the list in #18 originates from, but it has little to do with the tier languages :)

I was given that list by PM -- and yes, it's indeed different from the tier list of CODE10.

Michl, please clarify.

I'm especially interested how Norwegian and Finnish got on the list. Especially Norwegian is interesting - especially as such a language does not officially exist :)

The language 85% of norway speaks is Bokmal and has the 111st most native speakers in the world. 

The missed Italian is 18th btw, source:
http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers

Sorry, Italian was on that list but somehow got lost in the process. Here is the list for Michael to comment on:

  * English

Tier 1:
  * Portuguese (Brazil)
  * French
  * Italian
  * Spanish (Mid-Atlantic)
  * German
  * Chinese (Simpl.)
  * Chinese (Trad.)
  * Japanese

Tier 2:
  * Russian
  * Czech
  * Hungarian
  * Polish
  * Korean
  * Finnish
  * Danish
  * Norwegian
  * Swedish
  * Dutch

We take all tier1 languages. From tier2 we take all languages provided that they are localized at 85% and more (see http://i18n.opensuse.org/stats/openSUSE-10.2/index.php)

Do you really mean the 10.2 list - and not the 10.3 one (use trunk!)?

Correct, Michl wanted to point us to: http://i18n.opensuse.org/stats/trunk/

ok, looks like we have a winner. If not any suprises come up, we have a solution integrated into beta3

From the openSUSE POV, the concept of "tier" languages sounds wrong to me.  Nobody updates 'ja' ATM, 'es' is also incomplete, probably not updated since SLE10SP1 resp. openSUSE 10.2.

That's basically FYI.

I disagree. There is a difference between people working on it and people using it. And on the base that we don't have room for all languages on the DVD, I think it's a good measure. 

That these languages are incomplete is bad, but we should not change the list of languages too often. And it's my true belief that incomplete translations can bring in translators on board :)