Mailinglist Archive: opensuse-packaging (267 mails)

< Previous Next >
Re: [opensuse-packaging] Is there a quick way to test all Requires are in factory?
Hello,

On Wed, 21 Dec 2011, Claudio Freire wrote:
On Wed, Dec 21, 2011 at 8:26 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> 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 ;)

--
"I think I'd better donate something to SETI. Looking for
extraterrestrial intelligence seems a great idea, 'cause
there's bugger all intelligence down here." -- Dan Holdsworth
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups