Mailinglist Archive: opensuse-packaging (186 mails)

< Previous Next >
Re: [opensuse-packaging] translation-update-upstream: new package and feature
  • From: Stanislav Brabec <sbrabec@xxxxxxx>
  • Date: Tue, 17 Feb 2009 23:14:30 +0100
  • Message-id: <1234908870.7319.53.camel@xxxxxxxxxx>
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >