[Evolution] Anjal's using RPATH is an lintian error now

[Yves-Alexis Perez]

On jeu., 2009-11-19 at 16:27 +0800, Li, Yan wrote:
> On Mon, Nov 09, 2009 at 07:50:15AM +0100, Yves-Alexis Perez wrote:
> > On mar., 2009-11-03 at 15:59 +0800, Li, Yan wrote:
> > > Can we split those .so from evolution packages to separate lib*
> > > packages? I'm working on a patch to the evolution package now.
> > > 
> > I've prepared a split evolution/libevolution package for 2.29 in
> > experimental/ 
> > Not sure I'll upload it soon but you should be able to build it.
> 
> Anjal is not ported to 2.29 yet and will still have to rely on 2.28.*
> (for a considerable of time).

Yet, I won't split evolution 2.28. Too much potential breakage,
evolution is already unstable enough not to add a transition like that.
Plus, evolution 2.28 might be the version which will go in squeeze, and
I'd prefer not having a breakage there. (and I don't think anjal will go
in squeeze anyway).

I don't have time to take care of evolution, I'm just keeping up with
the new upstreams. I splitted the package in experimental, so users can
test it, but won't really do much more.
> 
> I've finished splitting 2.28.1 package into evolution and
> libevolution. But RPATH still has to be used and lintian considers
> using RPATH to be an error now. The .so files needed by Anjal is still
> in /usr/lib/evolution/2.28 (not in /usr/lib).
> 
> Per discussion with upstream developers, we think that Anjal should be
> considered part of Evolution, i.e. those Evo libraries should be kept
> private and should not be put into /usr/lib, since there's no
> intention to control the version or API of those libraries, which
> might be changed at any time.

Yeah, so much for the “low memory/processor/resolution devices”. Anyway,
I agree there's no point in moving them to /usr/lib
> 
> So to put it simple: per Anjal's design, it uses packages in
> /usr/lib/evolution/2.28, but this violates Debian Policy. I'm not sure
> whether binary-or-shlib-defines-rpath is really unacceptable here. Any
> advice on dealing with this?

I don't know if there's a clean way to do it but you might want to ask
on debian-devel at .

Cheers,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-evolution-maintainers/attachments/20091120/78a0da96/attachment.pgp>