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/
pgp77fbO4r8eo.pgp
Description: PGP signature