On Sat, 14 Dec 2002, Martin Albert wrote:
> Sorry, if you find i'm insisting or sth. like that. I feel that i have > unsolved problems (some more?: eg. module-versioning). > > Tell me to shut up or to try to do more mindreading about authors > reasons for those choices (am i not correct with: building up GGI, > concentrating on writing fine libs for the project with easy names, ...) > > I think your statement is correct and valid. > I think libggiwmh has it all: distinction, elegance, few chars to type. > Neither variant seems to be able to make both of us happy. > Either i'm confused or there are unsolved issues that confuse (me). > Decisions should be made before going further with release. Lay out a > stable concept with v.2 giving developers a clear view of a stable GGI. > > Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht > einfacher. "Keep things as simple as possible, but not simpler!" > If you don't take sth. upon yourself, somebody else _will have to_. > > greetings, martin (packaging gii, splitting x and really wondering / > worrying about module-versions. libgii-target-x or libgii0-target-x is > the question here, together with etc/ggi, lib/ggi all along). Well, I suppose my comment was directed more to authors of various extensions about the rather cryptic names of these extensions. Currently there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl in various stages of development. Maybe I'm just slower than most but meanings of a lot of these don't seem obvious to me. IMHO, flagging them as ggi extension by prepending their name with ggi is certainly a step in the right direction. As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. -Filip
