Hello, fellow developers! There is GGI and some basic packages for Debian do already exist (more? source ptrs: ggi-doc, libggi).
Most important: complete graphics environment, built up from libraries and (dyn-loaded) extension modules for lots of targets with varying dependencies. Having it all on the system might one day install every available graph related package, if only Depends were used. Modules detect availabilty of a library at runtime, so Recommends are used. Major issues here: naming, granularity of dependancies and install/runtime. Packaging: I'm looking for ways to help users, pkg and archive maintainers to find their way through. A consistent naming scheme and decision on granularity of dependancies are needed, a 'task package' might help installing and, most important, help with the runtime issue. Install/Runtime: GGI display targets are very versatile, some do read/write to/from files, tcp sockets, etc. The basic libggi2 binary pkg is usually depended on by packages that use ggi. There is one unnecessary problem that hits users, developers and the BTS: libggi2 provides some basic targets (file, tcp,...) and is very capable of doing usefull things with only them installed, like X clients with only a client library - you won't see any output (no Xserver) but everything is correct and meant to be that way. The same goes for libggi, you _may_ install display-targets that are Recommended or Suggested but you don't have to. The package description clearly states that you might want to install some and why. Now lots of users report bugs because they apt'ed and don't have display-targets (and don't RTFM, ... but bug), i hold some 12 bugs open to remind me and maintainers of the other pkgs of that issue. I thought about that for a long time, my stand is to do _nothing_: Descriptions, Dependancies, Recommends, Suggests and Enhances are meaningful and should be used. Not being able to select add. pkgs from maintainer scripts and Pre-Configuring make it nearly impossible to do sth. at install time, sending mail to root is ugly, installing default targets is senseless and ugly because of the sheer number of archs and their capabilities and more than often would a target be installed that is not the one the user would actually choose (choose from vcsa, terminfo, aa, svga, fbdev, X and additional arch-dependants) and some are suited better for a given task than others - this might even lead to real bugs then ;) What is the curr. consensus on 'Task pkgs' or the like? I'm thinking about ggi-user and ggi-develop, providing sth. usefull and draw other packages in - the snake bites its tail. So, what are the possibilities of installing additional packages from maintainer scripts and regular programs like ggi-conf. Granularity of Dependancies: GGI started out replacing X. As i took over libgii, that tiny little lib depended on X already. I still didn't dare to change this, afraid of bloating the archive even more. But it is wrong! There should at least be gii-X and non X. Libggi does the right thing, splitting display-targets. Still not consequently enough, but there are 9 binary display-target pkgs for i386 already, because of the varying dependancies. Naming Scheme: There are two 'real libraries', libgii provides input, ggi output and already needs gii. Then there are libraries for general display related operations (blit,ovl,...) that that might never be usable wo. libggi and for sure not the extensions, dyn-loaded modules extending display-targets. I intend to use: libggi-extNAME and libggi-libNAME for all of those. Planned pkgs would so become: libggi-extwmh and libggi-libgalloc. Ok? 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, - hold on current practice: libggi2 'Recommends' libggi-target-... - 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 - still not know how to solve the dependancy issues for users and maint. that cannot read. Please, gimme input, i'll sort it out. Maintainers of GGI aware packages, please (re-)consider building with GGI enabled. Greetings, have a nice Debian, martin
