Re: lablgtk2 -> lablgtk transition.
On Thu, Jul 15, 2004 at 09:55:50PM +0200, Sylvain LE GALL wrote:
> 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...
Yeah, i will backtrack the changes for it from svn tomorrow. It was
rather easy though, with the lablgtk binaries providing and replacing
lablgtk2, so as far as the package name was concerned, it would have
been transparent. It could still happen with just the name change and
keeping the lablgtk2 for the rest.
Please have a go at it, and build ocaml, lablgl and lablgtk from the svn
tree, and tell me what you think of it.
Friendly,
Sven Luther
Reply to: