Re: RFS: lesstif2
On Thu, 11 Aug 2011 20:06:29 +0200 Paul Gevers wrote:
>> On top of that, there are a few spelling corrections, and a couple
>> cases of refactoring/improving the code in the standalone version.
>
> If this is really the case, I would propose to get these improvements
> into the libxpm package (and upstream of course). What do you think
> about that?
Actually what I was saying is that the libxpm within the lesstif
package has remained stagnant for many years while the separate
libxpm has evolved, so those are in that package. You can see
this progression in the libxpm repo [0].
> About lesstif, I merely think that if we really want to improve lesstif,
> we should be working on the copy/paste issues. That part of the code
> really needs some attention which apparently nobody is able to give.
To be honest, I don't have that much interest in that feature, and
I have limited time, so I probably won't be able to work on that.
> > One issue that I see with your changes, although I don't know enough
> > about libraries to tell know if I am right, is that you reduced the
> > symbols (as lesstif doesn't have them after your change).
>
> Interestingly, an other discussion on this list [1], mentions the Debian
> policy (8.1) where it is stated that:
> """Every time the shared library ABI changes in a way that may break
> binaries linked against older versions of the shared library, the SONAME
> of the library and the corresponding name for the binary package
> containing the runtime shared library should change. Normally, this
> means the SONAME should change any time an interface is removed from the
> shared library or the signature of an interface (the number of
> parameters or the types of parameters that it takes, for example) is
> changed. This practice is vital to allowing clean upgrades from older
> versions of the package and clean transitions between the old ABI and
> new ABI without having to upgrade every affected package simultaneously."""
Hi,
I hadn't really thought about that, but that's a very good point.
I'll try recompiling all the reverse deps to see if this is going
to be an issue or not. Hopefully most have moved to standalone
libxpm already; otherwise we'll need to come up with a transition
plan.
> I guess that answers more clearly what you should do with respect to
> lesstif, and as far as I understand means quite some more work than you
> have done so far. Nevertheless, personally I still consider it good to
> remove the duplication of code, but we should as the question if lesstif
> is worth this. In my last round of improvements, there was some debate
> about if we shouldn't remove lesstif completely from Debian, although I
> think since last time the state has improved a bit. We can of course (I
> still have upstream commit rights) again improve lesstif itself.
Do you have a link to that debate? I think it still serves a useful
purpose and if people are willing to maintain it, I don't see why it
can't stay.
> Apart from this, to find possible sponsors, I think it might help when
> you state that you are maintainer of one of the reverse
> build-dependencies of lesstif, and are thus keen on improving the state
> of lesstif.
I didn't really think about that, but yes, I ended up looking at the package
because I was trying to make xpdf better ;)
Best wishes,
Mike
Reply to: