On Tue, 10 Jul 2007 11:35:09 -0300 "Margarita Manterola" <[EMAIL PROTECTED]> wrote:
> On 7/9/07, Matthew Johnson <[EMAIL PROTECTED]> wrote: > > If I have the time and inclination maybe I will port it to gtk2, but why > > should I spend that effort when it's a perfectly good working program. > > Sure it's not getting new features, but it gets along fine without them. Personally, I would recommend that a port is at least explored. It might not be as much work as quicklist et al. > Because, as it has been already said in this thread, the libraries > that your package uses are deprecated, unmaintained and prone to have > many undiscovered bugs. I wouldn't call the problems undiscovered - unlikely to be fixed is much more relevant. New bugs in libglib1 and libgtk1 that affect unchanged packages could arise from toolchain issues where changes in libc or gcc expose flaws in the libraries but when the application upstream is dead, there are relatively few places for new bugs to be found. I'd expect general bitrot problems to cause FTBFS bugs due to issues in old autotools etc. before a genuinely new security bug appears in such old code. Of course, FTBFS is a prime reason for removal of the package from the archive so maintainers of packages like gaby, quicklist and gbib do need to be able to work on those. A binNMU like the one that has just taken place on libglib1.2 is one source of such problems. Example: #359299 (I'll probably NMU this one if nothing changes in the next couple of weeks. It was filed a year ago as "important" but it's only been RC since I bumped the severity today due to effects on gnucash after the binNMU on libglib1.2 - yes, gnucash still depends on libglib1.2, despite all the efforts upstream and it's because of this bug.) Old libraries being used by NEW applications are the big problem - especially when the application (like gnucash) ends up depending on both the old *and the new* libraries! > Using unmaintained software always has this risk, but using > unmaintained software that uses unmaintained libraries is even worse. To me, the worst case is the current situation with g-wrap - an old package using old libraries but used *by* packages that are linked against the NEW libraries. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpk59LGBXBz2.pgp
Description: PGP signature
