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. ;) 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, and when an updated i18n add-on is published upstream, the user would need to install it manually. On the contrary, if i18n is included within the main k3b package, a k3b package update would install the language files automatically. I've submitted a patch for k3b to add a --disable-libmad option to the configure script, which -- when integrated upstream or patched in with autoconf -- could be used to build without MAD mp3 support, even if libmad-devel is installed. This would get rid of the "buildconflicts: libmad-devel" for "--without mp3" builds, and is primarly of interest for end-users and well-defined builds. Another thing to decide on would be whether to provide a k3b-mp3 add-on at rpm.livna.org (I will submit the fedora.us approved package there) or whether to provide a complete k3b including mp3 support? I would prefer the former, but (just like xmms and xmms-mp3) it creates a small time window during which users installing a fedora.us update would be without mp3 support, because the mp3 add-on is not published. The good thing about an k3b-mp3 add-on is that users need not update a fedora.us k3b with an mp3-enabled full livna k3b. --
