Vincent Untz wrote:
Hey Stanislav,
Do we really want to manually update all spec files? It's not that hard if we only do that for GNOME packages, but if we want to have the complete distro using this, that's a different story. People will also forget to use this when adding new packages, I guess.
People have to define upstream resources in the tool configuration (e. g. upstream SVN server and interesting branches inside), otherwise the tool will not collect anything. This is a one-time update. Once it's done, you don't need to update po tarballs any more (the way we use in recent).
I didn't realize that earlier, but for SLE, once it's released, we don't rebuild packages, do we? (or well, I guess they're rebuilt with SP1, SP2, etc.) I would think we'd want to just provide updated lang packages?
Yes, the tool limits a it can provide translations. Submitting translation-update-upstream triggers package rebuild. Any attempt to update translation without package rebuild forces overriding of all strings provided by packages. It would require strict policy: - No po updates allowed in spec files. - No translation fixes allowed in spec files. - translation-update will become a "must have" package, as it contains translation fixes. If SLE packagers and users can live with these limitations, then it's possible to use the simpler way. It's impossible for SLE10/SLE11.
A: Such large change cannot be done in late beta or rc phase. It must be ready as soon as possible, only translation data file updates will have to be done in the rc phase.
Hrm, this sounds wrong :-) If it's not interesting for openSUSE, then, well, it just shouldn't go in openSUSE. So the question is "how can we make it interesting for openSUSE?". Since the packages won't be rebuilt once a version of openSUSE is released, I was thinking that all the logic you implemented could be used for updating the bundle lang packages.
bundle-lang is created from a particular language files after package build. You can move the merge there at cost of introduction of a strict po-patch policy and a bit higher process complexity. As bundle-lang packages don't cover the whole distro (and also version upgrade forces non-bundled lang package), you cannot prevent spec file editing at 100%. Translation-update package (not my -upstream one) does not need package rebuild at all, but it forces its strings overriding any fixes in packages. It would again require introduction of a strict po-patch policy. Without enforcing the strict po-patch policy, the tool was ready for SLE10 SP2, but quickly rejected: https://bugzilla.novell.com/show_bug.cgi?id=377971 (restricted) But maybe this simpler tool would be interesting for openSUSE. Updated strings are here and there are two ways to update: - during compilation: all our fixed are kept - as an extra package: all our fixes are overwritten by upstream
As much as I hate divergence from upstream... I also hate manual work. It sounds to me like we could have %setup look at some file to know if a package should be using this feature, and if it should how it should use it.
Yes, it is possible, but it would make hard time for people trying to build broken packages. Example: gtk2 in SLE11 has a broken distcheck => such %setup would fail. Now you can simply work-around this brokenness by commenting translation-update-upstream or gnome-patch-translation-prepare out. With a %setup reading a configuration, it will not be possible.
Okay. Stepping back a bit. Could we make something export the POT files of all packages, and then have your scripts run on those files, independently of the package build? This is non-intrusive for packages, and it would make it easy to build updated lang bundles.
No. pot files don't exist in general. translation-update-upstream source contains a pot collection tool that calls obs and gets all needed pot files. Note that gnome-patch-translation does a very similar job. translation-update-upstream is even smarter: It reviews all po files inside and packages only differences. It reduced the size of translation-update-upstream from 90MB to 3MB. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org