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
