> 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.
Do you mean, the GGI project does exist in many other forms and variations, too? That would be very very bad... due to lots of double work... > 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. Such 'bug's should be auto-closed with 'Hey, this is not a bug. This behaviour is well documented. Please RTFM.' > 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. Sounds good to me. > 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. the default libgii package should come with common used/useable sublibs such as the filters and stdin. package dependencies should mirror the code dependencies. For example, someone installs the libggi package. libggi depends on libgii, so libgii is autoinstalled along with that. Then the user decides to use the x-target and installs the x-target package. This depends on libggi and on libgii's x input target. libgii's x input depends on libgii. So, as libggi and libgii dependencies are already resolved, only gii's x input target is autoinstalled along with ggi's x-target package. Second example: Someone installs libwmh's x-target package w/o having installed everything else before. So first, this x-target depends on libggi's x-target and on libwmh. So finally get installed: libwmh, libggi, libgii, libwmh's x-target, libggi's x-target and libgii's x input target. You see? > 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? libgalloc is an extension, too. so libggi-extgalloc. And libwmh's x-target name would be libggi-extwmh-x-target or something. ggi libs are libs like libgpf and libgic. (libggi-libgpf) The difference between ggi libs and ggi extensions is, extensions are aware of the target, libggi's uses at runtime. > 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. Is ok with me. You may also have a look at libgcp (http://www.ggi-project.org/libgcp.html) > Please, gimme input, i'll sort it out. Maintainers of GGI aware > packages, please (re-)consider building with GGI enabled. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] P.S.: Still haven't seen the buildlogs of -rc5. Not yet builded? +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
