[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: GGI with Debian

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 

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

Reply to: