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