On Thu, 02 Oct 2008 16:45:37 +0200
Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le jeudi 02 octobre 2008 à 15:21 +0100, Neil Williams a écrit :
> > Can we not separate the entire DirectFB question into dedicated packages
> > using predictable filenames and directories - just as if these were
> > actually different source packages? Would the DirectFB support need to
> > conflict with the non-DirectFB and would such a conflict work? If not
> > conflict, maybe we could rename the libraries to sit alongside each
> > other in /usr/lib/ ?

> The approach you are suggesting is to make Cairo behave like GTK+, but
> it contradicts what the Cairo API says, and it breaks the GTK+DirectFB
> build system.

OK, just an idea.

> > As you note below, diversions are also a possible mechanism (although
> > implementing diversions in Emdebian has separate problems that need
> > their own solution) but moving aside a library with a divert and
> > replacing it with a library containing a different list of symbols
> > whilst applications are still using the old symbols could be a problem,
> > that is why we have library transitions after all.
> 
> Not if the diversion is guaranteed (through dependencies) to divert the
> very same version of the library, only providing another version with
> more symbols.
> 
> > Does this not risk the subtle and incomprehensible bugs described
> > earlier? Typical DD has normal libcairo installed, needs to test an RC
> > bug in some other package that uses DirectFB, installs libcairo-directfb
> > which diverts (the running) Cairo/Gtk/Pango libraries and runs the
> > build. Maybe the user logs out, later logs back in, removes
> > libcairo-directfb and dependencies when the bug fix is uploaded, the
> > diversion is reverted and the DirectFB symbols are in memory but no
> > longer in the undiverted library?
> 
> This would really be the very same version of the library, with more
> symbols. Nothing can break more than when you simply upgrade the library
> to a new version.

Except that the diversion can also be undone and the symbols removed -
akin to downgrading the library to the old version. Anyway, I'm not
sure we need the diversion.

> > IMHO, putting the DirectFB symbols into the default
> > Debian /usr/lib/libcairo.so (without the diversion) is the best solution
> > for Lenny.
> 
> That, I agree with. But it can also become a long-term solution.
> 
> > IMHO /usr/lib/libcairo-directfb/ should not exist in Lenny (or Squeeze).
> 
> Yes, it’s a bit late, but I think we should remove it.

I agree.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgp77fbO4r8eo.pgp
Description: PGP signature

Reply via email to