Re: elinks to be REMOVED from squeeze?
On Sat, Jan 23, 2010 at 03:43:42AM EST, Freeman wrote:
> On Fri, Jan 22, 2010 at 09:32:26PM -0500, Chris Jones wrote:
> > On Fri, Jan 22, 2010 at 09:09:40PM EST, Freeman wrote:
> >
[..]
> I hadn't thought much of it and scarfed libtre5 from sid. Will it not
> install to lenny?
Probably would, but I'm not that hot on regex's, and besides I had some
real worries with ELinks, so ignored the libtre issue.
> > I recently installed the 0.13 git version of ELinks to resolve an
> > unrelated issue and since lenny does not feature libtre5, the
> > ./configure step gave me a warning and I was able to compile ELinks.
> >
> > The resulting ELinks version does not have the regex search capability
> > on the search dialog, which is not a major problem where I'm concerned
> > since in some 4-5 years of daily utilization of ELinks, I have never
> > needed it.
> >
>
> Right, libtre5:
>
> | a regexp matching library with approximate matching.
It looks like it is _the_ regex library in GNU/linux at this point, and
that it provides advanceds feature such as approximate matching on top
of the 'regular' :-) stuff.
> > I don't see why a dependency that would deprive you of an obscure
> > optional feature such as this, which by the way is correctly handled by
> > the stock ELinks install, would prevent installation of the debian
> > package.
> Possibly one reason aptitude will still download a broken package despite
> that the force option is gone?
I am not familiar with aptitude, but I would assume that there are good
reasons libtre5 is not yet part of testing.
> > As to the reason why ELinks of late requires libtre5, I suspect it has
> > something to do with Unicode support, which has been vastly improved in
> > recent versions.
> Yes. I hope it will not be an elinks issue. I am fond of both elinks and
> Unicode.
I tend to stick with stable and end up compiling from source the latest
versions of the half dozen applications I use on a daily basis and
running them out of /usr/local. Probably not a very debian-ish
approach, but then the parts of the system I know nothing about are rock
solid, and as to the stuff I compile myself, I either know enough about
it to fix it, or know where and who to look up in case it breaks.
> > I am not going to investigate this, but the output of 'git log' against
> > my git clone strongly suggests this.
>
> Very different bug definitions. Mine regards testing, compels me to
> ascertain info and maybe file a report. Your's regards mixed-stable, seems
> to involve triangulation and esoteric discussion. :)
:-)
Seriously, the thing is that as explained above, the applications that I
use often enough to run into bugs are not debian-packaged, so the bug
reports would only concern the upstream developers. Leaves stuff like
hardware issues, and minor annoyances that are usually not worth
reporting.
CJ
Reply to: