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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org