[Fedora-packaging] one big SRPM for lots of different stardict dictionaries?

Ralf Corsepius rc040203 at freenet.de
Tue Jun 26 08:26:04 UTC 2007

On Tue, 2007-06-26 at 09:33 +0200, Thorsten Leemhuis wrote:
> Hi,
> I stumbled over the CVS branch creation commit mails for a package
> called "stardict-dic" in my inbox and thought "hey, nice, someone
> packaged dictionaries for startdict". But then I took a closer look at
> the package and the review bug
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231267
> and got a bit worried.
> The plan of the packager afaics seems to be to get all the current and
> future dictionaries for other languages into this one just-reviewed and
> approved package stardict-dic (SRPM currently 84 MByte in size afaics),
> from with multiple sub-packages get build (currently:
> stardict-dic-{en,ja,ru,zh_CN,zh_TW} ).
> The "one SRPM for all dicts" approach IMHO has major disadvantages IMHO:
> the SRPM will become really big if dictionaries for other languages
> become part of it. This might be acceptable, but for each added dict or
> each bug that gets fixed in one of the dictionaries the whole SRPM gets
> rebuild and thus all the stardict-dic-{en,ja,ru,zh_CN,zh_TW} packages
> get created newly as well, which creates a lot of load for mirrors and
> users to download and install (¹).
> This sems very wrong to me; or am I overacting here?
No, I am inclined to agree with you.

> I'd say we should work towards a scheme similar to hunspell; e.g. one
> source package per language. Other opinions?
One "srpm" would be appropriate if upstream ships one monolithic tarball
or always generates all subpackage's tarballs from the same master
source tree (CVS, SVN, etc.) at the same time (E.g. GCC does this, they
are shipping alternative "monolithic" and "split" tarballs).

Also consider: At the very moment the dictionaries' versions should
diverge, this monolithic srpm enter problems with EVRs.


More information about the Fedora-packaging mailing list