Hello,
On Wed, 21 Dec 2011, Claudio Freire wrote:
On Wed, Dec 21, 2011 at 8:26 PM, Greg Freemyer greg.freemyer@gmail.com wrote:
Maybe a osc build sub-command could be created that tells osc to install all requires packages in the chroot env as well as buildrequires for an automated test without that manual specfile editing.
I'd say just checking they're there and are "installable", without actually installing would be nice.
Seconded. Although: usually[1] all "Requires:" are required by "BuildRequires:" anyway, not the other way round (e.g. you don't need gcc to install the libfoo package).
Speaking of requires: I think rpmlint needs a new check: a package SHOULD NOT ever require its -lang package. If it does, the purpose of a -lang package is counteracted and the -lang stuff could just as well be packaged in the main package. WHY in @DIETY's name split out something you'll require anyway and that won't be used by anything else? Hello? It's not a shared lib for fsck's sake, it's translations. Recommends, Suggest, fine, if you must. But Require? *gah*
I dislike to install tons of languages I have no idea about just because I might need the german translation.
What would be really cool were if we could create a lang-repo and do something like this:
* have (all) packages, esp. well translated and much needed ones like glibc) split out -lang packages (well, if there's only C (=en) plus 1 or 2 more, I'd be lenient). Splitting out a -lang package is not much work for a packager and is often done already.
* The repo accepts the submitted -lang packages, takes them apart, splits them after languages automatically creating foo-lang-<LANG> rpms, possibly merging some stuff (e.g. en_* into en, even if there are seperate en_US / en_GB .. .mo files). That system should not get into variants/dialects etc.
* There could be lang-bundle-rpm made out of those (like bundle-lang-kde-en) for interdependent stuff, e.g. you need libkde, kde-base and stuff for _any_ kde app, so, bundle those -lang packages, but keep e.g. k3b-lang-de and kaffeine-lang-fr seperate (and both depend on bundle-lang-kde-de/-fr respectively)
That way, the user should be able to configure and get a set of languages (e.g. C, en, de, fr, but not es, zh, ...) that would be installed.
Scripting that should not be to hard, parsing the package-names will be the hardest I guess if the script has no "other" knowledge.
- take foo-lang-<version> - install / rpm2cpio (to %{buildroot}/) (--nodeps --force, we're only repackaging and massaging deps if applicable ;) - cd %{buildroot}/usr/share/locale - foreach dir in */LC_MESSAGES; do lang="${dir%/*}" # create a foo-lang-${lang}.spec (on the fly? Must try if rpmbuild # will use stdin ;) but a tmpfs will suffice, and create a # file-list with %{_datadir}/locale/${lang}/LC_MESSAGES/foo*, a # "Requires: foo\n Provides: foo-lang-${lang}", probably massage # "Requires: foobase-lang" into "Requires: foobase-lang-${lang}", # and package up ${lang}/LC_MESSAGES as foo-lang-${lang}.rpm done - off with foo-lang-*.rpm to the servers ;)
I think a simple 'rpmbuild' there will suffice, as there's nothing fancy, just a repackaging. If it suffices to use librpm or cpan's *RPM* modules can do that repackaging and inserting/adjusting deps, that'd suffice. Ouh: the RPM4 perl module looks promising at first glance, but seems not to have been developed since 2007. *sigh* Maybe another.
Anyway, a simple repackaging .spec using just a rpmbuild (not an OBS/osc instance) should be no problem. And guessing from how long it takes just to setup a build-instance in OBS for the simplest rpm, I think a single OBS-instance-equivalent kept running could probably handle the -lang packages from the other instances ... Maybe (as it's just repackaging), it could even run on some ppc64 obs-servers that must be quite depressed and have worn down their thumbs quite a lot from twiddling them, chronically having nothing to do ...
Caveats: a lot more packages on the servers, maybe one should/could even split up repos by lang (cf. devel:languages:perl:CPAN-*) ...
Motivation:
# du -hs /usr/share/locale/ 249M /usr/share/locale/ # find /usr/share/locale/ | wc -l 6375 # find /usr/share/locale/{en*,de*,all*,curr*} | wc -l 529 (+1 for locale.alias). # find /usr/share/locale/{en*,de*,all*,curr*} -printf '%s\n' | \ awk '{s+=$1;}END{printf("%.1f\n", s/1024);}' 14108.5 # find /usr/share/locale/ -printf '%s\n' | \ awk '{s+=$1;}END{printf("%.1f\n", s/1024);}' 237078.9
That's quite a bit of files and diskspace. Esp. compared to what I actually want. And I do already have e.g.:
bundle-lang-gnome-extras-en kdebase4-openSUSE-lang gimp-lang konqueror-plugins-lang bundle-lang-gnome-en bundle-lang-common-en bundle-lang-kde-en
as "taboo" and "broken" packages that require those ... The crass misproportion of wanted and unwanted and the br<censored> idea of making foo require foo-lang is what gets to me.
Well, maybe a brain fart, maybe not ...
-dnh, using "taboo" and breaking packages regularly also because of that. I install lang packages only if I need the german GUI to help others (i.e. to be able to start the App with LANG=de, to e.g. tell them go to "Hilfe" -> "Über ..." instead of "Help" -> "About" (well, not for that but for something e.g. deep in the Prefs-dialogues of seamonkey)). Or if the C-Locale of that package is not english (or german, which it should not be but I wouldn't care in that case).
*getting in his asbestos suit, just in case*
[1] can't think of a counter example right now, hm, maybe some icon/theme package?
PS: in this mail, xemacs surprised me a couple of times by DWIM (e.g. when reformatting the comment stuff in the above "foreach" block), but, yes, in other modes / use cases, it doesn't. Just a pleasant surprise this time ;)