Samuel Thibault <[EMAIL PROTECTED]> writes: > Package: libbrlapi1 > Version: 3.7.2-7 > Severity: normal > Tags: patch > > Hi, > > Yes, this is a bit contradictory with what I said in #384254 and > #357860... > > Julien Cristau made me realize that shippping xbrlapi and > libbrlttybba.so in libbrlapi1 will pose problem when moving to > libbrlapi2 (or other versions) some day: both would provide them, so it > would be impossible to keep both versions installed.
Ouch, I knew there was something fishy with the idea of moving an executable into a library package, but I wasn't thinking enough to remember there is even a rule that forbids this for the very same reasons. This will teach me to not trust user bug reports that blindly in the future :-/. > What we may do is > > - moving back libbrlttybba.so into brltty, where it belongs, since the lib is private and has no versioned soname. Creating yet another binary package solely for this driver looks pretty silly and pointless. > - and moving xbrlapi into brltty-x11. Which would remove the unnecessary X11 library dependencies from libbrlapi1. > That way, brltty will now depend on libbrlapi1, but that will at least > not pull the X11 dependencies via xbrlapi. It looks like an improvement dependency-wise, but still with a drawback... I guess trying to link libbrlttybba.so with libbrlapi(.a) is not really an appeling approach? On one hand, it might be useful since it ensures the not-versioned private library always gets to run the BrlAPI version it was compiled with. But thats a upstream issue anyway, but we should maybe think about it for 3.8. In any case, whatever we do, we need to do it fast, since if we can't get this right before etch we'll have to deal with the resulting upgrade breakage in the etch->lenny upgrade period... -- CYa, Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
