k3b,-i18n (and xmms/-artsplugin, koffice/-i18n...)

[Rex Dieter]

Michael Schwendt wrote:
> On Fri, 19 Mar 2004 13:15:03 +0200, Mihai Maties wrote:
> 
> 
>>[...] since Rex is using exactly your src.rpm to build the packages.
>>I am aware of the policies involved and my intention was to continue
>>packaging K3b for fedora.us based on your spec file not mine.
> 
> 
> This sounds like Rex wouldn't mind if you became the k3b maintainer. ;)

Sounds fine to me.

I'd rather concentrate on the core-kde packages, which reminds me I 
should be submitting a bunch of buzilla's for those before it's too late 
for fc2...

> If I continued the packaging, I would merge the i18n files into the main
> package (thereby ignoring any users who like small installation
> footprint), obsoleting k3b-i18n, for the following reason. There have been
> times when a new k3b release was without an i18n add-on, and then the new
> k3b package would obsolete/erase an out-of-date k3b-i18n, 

First off, why bother Obsoletely k3b-i18n?  So what if it's 
(temporarily) out-of-date?  Besides...

If it matters any, I personally would much rather k3b and k3b-i18n be 
packaged separately.  My (strong) opinion is, in the absense of a strong 
case otherwise (and I don't see one here), if the developer packages it 
separately (ie, separate tarballs), so should the rpms be packaged 
separately.

This argument holds true here for k3b/k3b-i18n in addition to some other 
items like:  xmms/xmms-artsplugin/xmms-skins, koffice/koffice-i18n

In this case, the -i18n portion gets updated much less often than the 
k3b part, save folks the hassle of redownloading/reinstalling the same 
i18n portion *over* and *over* again for every k3b upgrade.  There is 
also the space issue (as you mentioned) of forcing everyone to install 
the -i18n portion, whether they want/need it or not.

-- Rex