Magnus Boman wrote:
On Tue, 2009-02-17 at 16:40 +0100, Stanislav Brabec wrote:
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.
rpmlint could be extended to catch all of the potential issues with packages that we build for openSUSE
rpmlint cannot do it. You need to perform actions on a complete source tree to perform this check, checking of build RPMs is not sufficient. Error can be caused by strings in the upstream SVN, outside of our spec files and outside OBS. There can be no check preventing it. If the package does not support translation in a standard automake->gettext way, forcing the check may fail in an arbitrary way (and guessing whether po files are supported exactly in the standard way is not trivial). Adding "make distcheck" to the %check stage of our packages would surely prevent many QA issues (including some translate-ability problems), but at cost of double compilation time.
Q: Isn't it best to modify OBS to support this?
A: No: - The tool has to have access to network.
When doing this during compile time, the tool doesn't have access to the network. Why would it be different if OBS had to handle it?
In my opinion, any action, that significantly modifies unpacked sources should be part of spec file (or macro) and not the Build Service, not counting the fact, that OBS simply cannot initiate any action in the middle of %prep script. Move it to OBS would make things even more opaque: - OBS would build different RPMs than rpmbuild. => You will not be able to fix rejects in po file patches. - Configuration file for translation update would be hidden somewhere deeply in the OBS repository configuration. => After linking to other repository, you would get a different RPM or failure. - Complete po files merge for the first 100 packages requires about 2 hours with a fast network, fast machine and low servers load. How you will schedule this action inside OBS itself? - It may merge buggy upstream translation. => You would have to design OBS API to control the merge behavior.
- String collecting may require manual intervence in case of upstream errors.
See rpmlint suggestion above
rpmlint cannot catch errors in the upstream SVN repository.
Q: Wouldn't it be better to modify %setup?
A: No: - It would bring additional "magical" divergence from upstream.
But if %setup is extended only in OBS and only for repositories that are actually built for SLE, it wouldn't diverge at all for openSUSE packages.
It would be very problematic. If only SLE version of %setup will understand the new %setup argument, say -G (skip translations update from upstream), how you can base SLE on openSUSE code base? Without -G it can fail due to possible error or non-standard gettext directory, with -G it will fail in openSUSE due to unimplemented option.
- Things may need tuning (e. g. for non-standard po directories)
See rpmlint suggestion above
How you would define, that gimp needs update of four po directories without breaking compatibility with a standard %setup command (see above)?
My view of this is, that when building SLE (which I guess is not done in the public OBS) the %setup macro could be extended to do this work automatically.
It cannot be done automatically. You need to specify: - that update is needed - which additional directories need to be processed - if upstream package contains gettext error, you need to apply patch before calling the script And for the collection tool: - define where to search for strings in the upstream SVN, CVS...
While openSUSE is being packaged and built in the public OBS, rpmlint can do the checks that are in place for this tool and generate a warning. The people involved in SLE would simply have to check the build result of packages that are of interest and fix them as appropriate. So once packages are copied for a new SLE version, there should be any errors.
When openSUSE Gold Master is released, its development continues as SLE. To prevent breaking of the system, only important fixes and minor changes can be accepted. It's impossible to change the whole build system behavior in this moment, and it's impossible to depend on repositories anywhere on the web, that may arbitrarily change.
Adding a BuildRequires and the needed line after %setup to each .spec file would, in my opinion, make the package less portable to other distros etc since it either have to be removed or one have to add %if checks.
Packages that are not part of any translation-update-upstream configuration file don't get translations merged from upstream. => You don't need to call translation-update-upstream. It is useful only for official openSUSE packages. If you want to recycle openSUSE package, you can simply use translation-update-upstream package as well. If you don't do it, then yes, you would need %if. As you already need %if for update-desktop-files, I see not a big problem there. By the way, gnome-patch-translation use the same %prep+BuildRequires approach. -- 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 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