k3b fedora.us reviews or new maintainer wanted!

Mihai Maties mihai at xcyb.org
Mon Mar 22 09:41:10 UTC 2004


On Friday 19 March 2004 18:49, 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. ;)

OK :) Just give me some time to get to know the fedora.us/livna policies a 
little better. Right now I'm caught with some problems at work but in a few 
days I'll contact you for further instructions.

> 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 would go with Rex on this one. In the past few months there were a lot of 
minor K3b releases (7 to be precise) that used the same i18n files. This 
would be 2.5MB * 7 ... it's quite a lot.

> 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.

Great. Any news on that ?

>
> 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.

Sebastian Trueg just released a separate archive with a plugin for adding 
Monkey's Audio support to K3b. He did not include the plugin directly into 
K3b because he didn't receive an aswer regarding the license. Theoretically  
the library is free but he's just playing safe.

Since he splitted his source tree I believe the best aproach to this would be 
to separate the packages too: k3b, k3b-mp3 and k3b-monkeyaudio. We could even 
patch K3b to display a warning message if someone is trying to handle mp3 
files and he/she doesn't have k3b-mp3 installed (xmms style).

In time, if we find this to be a "not too good idea" we'll just move the 
package to livna and obsolete k3b-mp3 . By the way, is there anything it can 
be done to minimize the time window between the release of k3b on fedora and 
k3b-mp3 on livna ?


Mihai





More information about the fedora-devel-list mailing list