[opensuse-packaging] While updating purge translation-update
https://bugzilla.novell.com/show_bug.cgi?id=353229 translation-update is already in use (for SLED 10) and we also want to make use of it for openSUSE. Thus the bug already exist. coolo wants me to open the discussion about this feature on the list. Here are the statements already posted: As part of bug 350693 we release "translation overrides" translation-update for 10.3. Package names are translation-update and as sub-packages translation-update-de, translation-update-es, translation-update-fi, translation-update-ja, and translation-update-pt_BR. In the past, we did something similar for SLE10 and SLE10 SP1 (more to come). At update time we must make sure to remove these packages. To make this happen, I'll add empty packages for 11.0 (and, if wanted for SLE11). Now we must find a way, that translation-update and the sub-package will always be available on the installation media (and in the patterns?). See Ladislav's comment in bug 350693#c2 : Date: Thu, 6 Dec 2007 15:15:53 +0100 From: Ladislav Michnovič Subject: Re: [opensuse-translation] translation-update 2007/12/6, Carlos E. R. <>:
The Thursday 2007-12-06 at 10:46 +0100, Karl Eichwalder wrote:
For LCN it would be harder, because the translations are distributed in various packages.
This could be done using the overload strategy with the shadow directory for the .mo files. We did those things for SLED10. The package name is translation-update.
The tough part is to get rid of the package if you update from 10.3 to 11.0.
Ouch.
It has to be an optional package, with a warning to the user; and then try to remind whoever does that in Yast development to remove the package on upgrade... not a clean solution, it can backfire.
I have an idea how to solve it. Create this package within Suse and do a proper numbering. For example 10.3.x.y, which shows, that it is connected to openSUSE Linux 10.3. Release translation updates as often as needed, but when next SuSE release comes, renumber it to 11.0.x.y and make this package empty. This package will come within installation media and it would be without any files, only README for some information. If somebody will do an update, YaST, zypper, rpm can handle this and will erase all files which was installed on the system by that package in previous version. One thing is needed, to make some dependency on some basic package or Pattern which will ensure, that this package will be always installed. Ask YaST2 maintainers for details. Regards Ladislav. Comments ------- Comment #1 From Lars Vogdt 2008-01-11 18:08:29 MST [reply] ------- Private Just my 2 cents: I don't think that this is the right way to go: I expect the translations in the "real" package resp. the package-lang file. And only these files should be updated if needed. So I vote that translations should go into the packages themselves so the package maintainers know what's happening with their package. This needs perhaps a bit more background work to sort the translations into the correct packages again, but this would also give us the possibility to upgrade just a single translation - and even the user has just to download translations for packages he wants to have. (Just think about users with a small internet connection.) But apart from this: installing some "pseudo" packages to obsolete our patch-framework is a good idea ;-) ------- Comment #2 From Lars Vogdt 2008-01-11 18:12:07 MST [reply] ------- Private Just have a look at #255716c2 to get an additional idea why I'm agains an additional package. "Several packages were dropped or renamed"... ...and perhaps even not installed on the users machine.... ------- Comment #3 From Karl Eichwalder 2008-01-14 01:38:44 MST [reply] ------- Private Touching "frozen" packages just because of updated translation files is not an option. At least it did not work in the past. Bug 255716 is unrelated. Package maintainers must learn not to fix translation bugs in their packages (once the product is released), but either add the fixed file to translation-update or ask me (or Ladislav) to do it. Since most package maintainers are not that fond of fixing translation issue, they might even appreciate to hear that we'd happily like to offer a helping hand. If we make sure to release empty translation-update-LL packages with every product (openSUSE/SLE), we are probably on the right track ;) -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Karl Eichwalder
Karl, me and the team are wondering why the lcn updates have been hooked to OO instead of yast2-trans-$LANG.
https://bugzilla.novell.com/show_bug.cgi?id=353229
translation-update is already in use (for SLED 10) and we also want to make use of it for openSUSE. Thus the bug already exist. coolo wants me to open the discussion about this feature on the list. Here are the statements already posted:
As part of bug 350693 we release "translation overrides" translation-update for 10.3. Package names are translation-update and as sub-packages translation-update-de, translation-update-es, translation-update-fi, translation-update-ja, and translation-update-pt_BR. In the past, we did something similar for SLE10 and SLE10 SP1 (more to come).
At update time we must make sure to remove these packages. To make this happen, I'll add empty packages for 11.0 (and, if wanted for SLE11). Now we must find a way, that translation-update and the sub-package will always be available on the installation media (and in the patterns?). See Ladislav's comment in bug 350693#c2 :
Date: Thu, 6 Dec 2007 15:15:53 +0100 From: Ladislav Michnovič Subject: Re: [opensuse-translation] translation-update
2007/12/6, Carlos E. R. <>:
The Thursday 2007-12-06 at 10:46 +0100, Karl Eichwalder wrote:
For LCN it would be harder, because the translations are distributed in various packages.
This could be done using the overload strategy with the shadow directory for the .mo files. We did those things for SLED10. The package name is translation-update.
The tough part is to get rid of the package if you update from 10.3 to 11.0.
Ouch.
It has to be an optional package, with a warning to the user; and then try to remind whoever does that in Yast development to remove the package on upgrade... not a clean solution, it can backfire.
I have an idea how to solve it. Create this package within Suse and do a proper numbering. For example 10.3.x.y, which shows, that it is connected to openSUSE Linux 10.3. Release translation updates as often as needed, but when next SuSE release comes, renumber it to 11.0.x.y and make this package empty. This package will come within installation media and it would be without any files, only README for some information. If somebody will do an update, YaST, zypper, rpm can handle this and will erase all files which was installed on the system by that package in previous version. One thing is needed, to make some dependency on some basic package or Pattern which will ensure, that this package will be always installed. Ask YaST2 maintainers for details.
Regards Ladislav.
Comments ------- Comment #1 From Lars Vogdt 2008-01-11 18:08:29 MST [reply] ------- Private
Just my 2 cents:
I don't think that this is the right way to go: I expect the translations in the "real" package resp. the package-lang file. And only these files should be updated if needed.
So I vote that translations should go into the packages themselves so the package maintainers know what's happening with their package.
This needs perhaps a bit more background work to sort the translations into the correct packages again, but this would also give us the possibility to upgrade just a single translation - and even the user has just to download translations for packages he wants to have. (Just think about users with a small internet connection.)
But apart from this: installing some "pseudo" packages to obsolete our patch-framework is a good idea ;-)
------- Comment #2 From Lars Vogdt 2008-01-11 18:12:07 MST [reply] ------- Private
Just have a look at #255716c2 to get an additional idea why I'm agains an additional package. "Several packages were dropped or renamed"... ...and perhaps even not installed on the users machine....
------- Comment #3 From Karl Eichwalder 2008-01-14 01:38:44 MST [reply] ------- Private
Touching "frozen" packages just because of updated translation files is not an option. At least it did not work in the past. Bug 255716 is unrelated. Package maintainers must learn not to fix translation bugs in their packages (once the product is released), but either add the fixed file to translation-update or ask me (or Ladislav) to do it.
Since most package maintainers are not that fond of fixing translation issue, they might even appreciate to hear that we'd happily like to offer a helping hand.
If we make sure to release empty translation-update-LL packages with every product (openSUSE/SLE), we are probably on the right track ;)
-- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (1)
-
Karl Eichwalder