[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Multimedia in KDE 3.5.8
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-09-30 16:34:09
Message-ID: 20070930163409.GA14153 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 30.09.07 09:15:14, James Richard Tyrer wrote:
> Andreas Pakulat wrote:
> > On 29.09.07 14:51:23, James Richard Tyrer wrote:
> >> Please discuss on kde-devel.
> >> 
> >> IIUC, we are making a new release.  I agree that this is needed. We
> >>  should continue to make bug fix released and maintenance releases 
> >> at least till 4.0.0 is released.
> >> 
> >> I notice that we have some maintenance issues in KDEMultimedia.
> >> 
> >> We do not appear to support the new MusicBrainz/TunePimp.  IIUC, 
> >> there is a new server and a new protocol and that the old server is
> >>  going to be taken down soon.
> >> 
> >> We do not appear to support the latest releases of Ogg/Vorbis. 
> >> However, MP3 works on OK with KDE players on my system.
> >> 
> >> I do not know the current status of aRts vs GLib.  I was running 
> >> 1.5.1 with Fedora patches which seemed to work OK.  I am currently
> >>  trying the SVN 1.5 BRANCH without patches built against
> >> GLib-2.14.1 to see if it will work.  If not, I will try to find
> >> some patches for a version newer than 1.5.1.
> >> 
> >> It appears to be that, if possible, these issues should be 
> >> addressed in a maintenance release.
> > 
> > You're about 2-3 months too late.
> 
> If you read what I wrote, you will see that I didn't say that it had to
> be for this release.  But, will it take 2 months to fix this?

Well, it might take forever, as "nobody is supposed to work on KDE3
anymore", at least not the core modules.

> > KDE 3.5.8 is scheduled for the very near future (not sure wether it 
> > was Oct 3rd or 10th) and is already 1 months "behind schedule". Also
> >  KDE3 doesn't have to support all the latest versions of all those 
> > things out there, IMHO.
> 
> The problem with this theory is that there are other applications out
> there that may require the new version of the library.  Unfortunately,
> although it is possible to link against a specific minor version so that 
> the old library can coexist with a newer version on the same system, 
> this is not usually done.  Mozilla does this with the C++ library.

Huh? If a library breaks binary compatibility its supposed to increase
it SOVERSION, if it does that, then there's no problem installing a new
and an old version of that same library into the same prefix. If the
library upstream doesn't do that, you should kick them in their fine
ass.

> > so maybe the "support" for those is just a matter of an 
> > autoconf-check change, which obviously distro's already do.
> 
> This is also a theory that I would disagree with.  We should not release
> a product that is defective and expect that the distros will fix it.

Well, as I said fixing 3.5.8 (if it really needs fixing, which I doubt,
I strongly suspect a local problem on your pc, at least for the
libogg-thing) is not possible and KDE4 is going to be released at the
end of the year. I doubt there will be another 3.5.x release, so this
discussion is just pointless. If distro's find themselves in a situation
where they need to fix kdemultimedia from kde3 because of whatever
reason they will either do that (possibly communicating with us about
possible fixes) or they will just drop kdemultimedia-kde3 and tell users
to use the kde4 version.

> Those are the current version numbers.  The question is whether you 
> built them and KDE from source or did a distro fix something. :-)

No, I didn't. But libogg didn't change their SOVERSION and thus the
library should be binary compatible. Also kde-stuff wasn't rebuilt after the
last libogg update, which indicates that indeed libogg is binary
compatible to its predecessor.

Andreas

-- 
Tomorrow will be cancelled due to lack of interest.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]