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
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
Reply to: