k3b fedora.us reviews or new maintainer wanted!

Michael Schwendt ms-nospam-0306 at arcor.de
Fri Mar 19 16:49:59 UTC 2004


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.

-- 





More information about the fedora-devel-list mailing list