Re: lablgtk2 -> lablgtk transition.
On Thu, Jul 15, 2004 at 08:48:43PM +0200, Sven Luther wrote:
> On Thu, Jul 15, 2004 at 08:20:09PM +0200, sylvain.le-gall@polytechnique.org wrote:
> > On Thu, Jul 15, 2004 at 03:42:01PM +0200, Sven Luther wrote:
> > > Hello,
> > >
> > > Altough it is still unanounced, lablgtk upstream has released lablgtk
> > > 2.4.0. I don't know what that means with regard to lablgtk1
> > > compatibility, but i will probably have the lablgtk package be this new
> > > lablgtk2 descendent, and provide a lablgtk1 package for backward
> > > compatibility.
> > >
> >
> > Hello,
> >
> > Well, at least for package mldonkey, there is still package using
> > lablgtk ( version 1 ). Off course, i can patch this kind of package, but
> > i also think that there is package using lablgtk2 ( ie not lablgtk ),
> > taking for example camlimages...
> >
> > Well, i am not an expert, but i think that the current split
> > lablgtk/lablgtk2 is accepted and changing this could lead to more
> > disturbance than advantages... Maybe you have better reason than mine to
> > do this transition... Could you just told us what does involve ( in good
> > ) this transition ?
>
> Well, the upstream source is lablgtk, and no more lablgtk2. It will also
> no more leave clutter when we remove lablgtk1, but apart from that i
> don't see.
>
> Furthermore the ocamllibdir subdir and dllname is stimm lablgtk2, so i
> am reconsidering. Also see my mail about this on the lablgtk2 list.
>
Yep, i have read it...
The answer of Mr Garrigue seems to prefer lablgtk2-XXXX... I understand
you wish to switch to lablgtk, but since lablgtk ( v2 ) is a major
interface changes, the library should be versionned 2 ( as with libpng,
libwhatyouwant )...
Let me explain you the way i think :
- there is still lablgtk ( ie v1 ) application in the wild
- if they don't have migrate to lablgtk2, the reason could be :
- unmaintained code
- no interest in using v2
- woody user ( yeah, lablgtk2 is not in woody -- as far as i can tell )
- ... ( not exhaustive listing )
- for the above reason we can conclude :
- unmaintained code -> the patch will never go upstream
- no interest in using v2 -> the patch won't interest upstream
- woody user -> they don't even have the ability to test the patch,
since they cannot install lablgtk2
- ... -> don't know
Off course, i rather prefer that all application using lablgtk migrate
to lablgtk2, but i cannot made all upstream agree to this idea...
The reason i prefer using lablgtk2 :
- people using lablgtk ( woody for example ) doesn't have to know that
it has been renamed, and that the library is not the same
- people using lablgtk2 ( sid for example ) doesn't have to read d.o.m.
to kow that we choose to switch to lablgtk
- don't need to remove the binary lablgtk package ( well i am not sure
we really need to remove it ).
To set things explicitely : i am not against the renaming, i just think
it is a complex task, for a minor effect...
Kind regard
Sylvain Le Gall
Reply to: