Martin Albert <[EMAIL PROTECTED]> wrote: > In short (hey, you didn't expect that?): If no one answers, i will: > - close all bugs wo. further notice, regarding the unavailability of > 'visible' output,
Ack. Those are very correctly closeable as "not a bug". > - hold on current practice: libggi2 'Recommends' libggi-target-... Yes. I use LibGGI in several strange ways myself, many of them not requiring a visible target. Simples example: mplayer. It has divX writing routines, but I'd rather opt for MPEG2/SVCD. Thus I have just written a few scripts utilizing mplay's ggi target and ggi's file target together with the tile target to spit out y4m-Output that will get encoded by mpeg2enc just fine. > - make as many binary packages as seem necessary to me (promise to do > it consciously and responsibly) > - name them eg.: libgii, libggi, libggi-extwmh, libggi-libgalloc Sounds good. > - still not know how to solve the dependancy issues for users and > maint. that cannot read. Yeah. Only thing we could do about it, is extend probing and reporting the findings a bit, like stating "you seem to have X running, but the LibGGI X target is not installed. You may want to add the appropriate package to your selection." BTW: If the split is not done for LibGII, it would be a good place to start doing so. Would be silly to need X to install LibGII ... However in a standard Linux environment (with dlopen working as expected), the dependencies should be "soft" i.e. only cause bailing out when one tries to use something that isn't there. But that can be annoying as well. Splitting the targets/inputs in appropriate packages is TRTTD. CU, ANdy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
