[Kde-imaging] kipi-plugins 0.1.5 available for testing

[Achim Bohnet]

On Wednesday, 12. March 2008, Angelo Naselli wrote:
> mercoledì 12 marzo 2008, Achim Bohnet ha scritto:
> > On Wednesday, 12. March 2008, Valerio Fuoglio wrote:
> > > Hi,
> > > kipi-plugins 0.1.5 is ready for testing:
> > > 
> > > http://www.valeriofuoglio.it/kipi/kipi-plugins-0.1.5.tar.bz2
> > > http://www.valeriofuoglio.it/kipi/kipi-plugins-0.1.5.tar.bz2.md5
> > 
> > configure check need an update. Installed is
> > 
> > ii  libkdcraw2                         0.1.3-1                            Raw picture decoding C++ library (runtime)
> > 
> > configure says:
> > 
> > checking for libkdcraw in our sources... not found in sources
> > checking for libkdcraw >= 0.1.2... yes
> > checking LIBKDCRAW_CFLAGS... -I/usr/include/kde
> > checking LIBKDCRAW_LIBS... -lkdcraw
> > 
> > but an build fails due to out of date libkdcraw
> Fixed thanks.
Hi Angelo,

Sorry, I did not make it clear: build failed with even with 0.1.3
installed. Really required is libkdcraw 0.1.4 (that has new API ;)

Sorry for generating confusion and the harsh comment in my last mail,

Achim
> 
> > > 
> > > Waiting your feedback  :)
> > 
> > A (pointed) remark: Due to all this lib API incompatibilities with
> > each release one has more or less to update/rebuild libk*, kipi-plugins
> > and all kipi host application together. This really sucks :(
> You're right, but as you know this breakage was planned at the end of last 
> year, we've talked together about it via IRC iirc.
>  
> > So updating is an all or nothing and not much fun, really.
> > When I think about backporting, then libgpod and exiv2 etc are
> > also out too old, then the real fun begins :(
> Well backporting kipi-plugins as well as digikam needs (often)
> a libkcraw/libkexiv2 backport, since they're growing and growing.
>  
> > We should really better try to a) avoid breaking backward compatibiliy,
> > b) collect API breaking changes and do them once together, and c) if not
> > too complicated ensure software build with the 2 last API version.
> Well it could be right as i told a lot of time in these last days, we need
> a better planning. In the next few days i will be happy to talk about 
> a kipi release plan (e.g. libkipi, libkexive2,.... - i recall libkipi
> and libkexiv2 have to be released asap for digikam and we've cahnged the 
> api and iirc broke abi) with those of whom want to either via mail or via 
> mailing list as well as vi irc (when i am present).
> 
> > Another way would be to move a kipi-plugin into it's own process (Hide
> > the implementation detail behind libkipi API ;)   This way kipi-plugins
> > and the kipi host apps could each use different API version of an lib
> > like libkdcraw1 and libkdcraw3,  libkexiv2-1 and libkexiv2-2 etc. 
> > without danger to crash.
> Sorry i don't get it. Do you mean we should use two differen libkexiv 
> for instance one for host applications and one, maybe statically linked
> for kipi-plugins?
> 
> > Just my 2 cents,
> 
> You know your 2 cents are often made of gold ;)
> 
> Angelo
> 
> P.S. Valerio has (as you've seen) updated the packages if the only problem
> is the kipi-plugins test we could upload it anyway with a note about a known
> problem into release notes maybe tomorrow. What do you think? 
> 
> 
> 



-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com