On Thu, 2017-04-27 at 13:31 +0200, David Tardon wrote: > There is a reason that libreoffice puts l10n data into separate > subpackages. Hi, yes, there is a very good reason for it and I'm not questioning that. libreoffice was just an example of a package which does that already, but also fails to do the right (or better "expected by me") thing, for which you gave a bug link. Thanks for it. As had been said in this thread, one approach doesn't work for all packages. I made it my way for the core evolution packages this morning for rawhide. There is only one langpacks subpackage. I looked also on syncevolution, because I've been curious, and the split translations package was around 90KB of size, thus it didn't make any sense to split the translations and I left syncevolution unchanged. That makes me think that there are these kinds of packages: a) without any translation - no changes for these b) with only a small translations - like syncevolution, split doesn't make sense c) with semi-large translations - packages, where split translations by language is less useful or impractical, thus one package with all languages is preferred/used d) with large translations - languages are that large that it's better to split the langpacks into per-language subpackages e) with large translations and additions - like libreoffice, translations split by language as well, but libreoffice also adds more dependencies to these translation packages (as you said). I did with evolution core packages what I thought is the best. I do not use weak dependencies, I define a hard dependency between the langpacks and the binary package, both ways, thus users get either both or none of them. That makes the change backward compatible, while still helping with disk usage on build servers and mirrors. One part of backward compatibility in this case is also related to d),e) above, where, for the way I made it, users can switch languages and they will have the UI translated without a need to install additional package(s). When starting this thread here, I did not intent to suggest any change on the build servers to do things automatically, I was more interested in ideas and opinions of other packagers. It would be nice to have these things done transparently, with minimal lines in RPM .spec file, but as there are a-b-c-d-e cases named above (and/or there can be found even more), then it makes it impractical. If this thread will lead to some "nice-to-have packaging guideline", then it would be welcome and more than I expected from it. > Btw, I'm not sure what do you mean by "divide langpacks by country". It's just a terminology. What I call "by country", other (more educated) folks call "by language/region/variant". Simply not-all-translations in one single subpackage. Thanks and bye, Milan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
