Subject: Re: old versions of packages
To: Miles Nordin <carton@Ivy.NET>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 10/07/1999 05:13:02
On Thu, 7 Oct 1999, Miles Nordin wrote:
> On 7 Oct 1999, matt debergalis wrote:
> > so, i don't want to break the arena package, but it'd be nice to have an
> > up-to-date libwww, and i'm not sure anyone really cares about arena.
> I tried to build arena on NetBSD/sparc a few months ago and found it to be
> so buggy on both a 1-bit and a 24-bit display as to be laughably useless.
> so i agree with you that removing the arena package wouldn't be the end of
> the world. I think arena is more an embarrassment at this point than
I've been playing with arena, too. I can't even click all the buttons
without it dumping core. I sniffed out one bug, where it frees memory
that hadn't been allocated, but there are clearly more. I should look
at Amaya. Yggdrasil seems to have dropped Arena like a hot potato. The
last few patches, to 1.6.2, aren't even in the ChangeLog.
> For my vote, I don't want an old libwww around if it's going to make it
> more difficult for someone to make an amaya package. If you could make a
> libwww-old package that used a different library name, update arena to use
> the different library name when building, and increment the major version
> number for your new libwww's library, you might be able to pull this off
For my money, you could just ditch Arena.
> A quick grep reveals that teTeX depends on libwww as well--you might want
> to investigate that, as i suspect teTeX is a lot more useful than arena,
> and really ought to keep working.
I suspect it's only a small part of teTeX that uses libwww (web2c?).
Even Arena builds against the latest anoncvs'd libwww, it just won't
link without changes to the Makefiles. libwww.a has been
factored into "modules", so libwww.a -> libwww*.
The latest "tar ball" release is 5.2.8, from April, although they're
currently at 5.3.1. You can get a weekly cvs snapshot as a tar ball,
but the current bootstrap procedure for libwww doesn't lend itself
easily to packaging: You need to build the headers with a perl script,
then run aclocal, autoheader, automake, and autoconf. I also found
that pkglibtool couldn't do it; but devel/libtool was OK. There's talk
on the list of committing the configure script, and otherwise
normalizing the build. IMO, it would be easier to just wait, but
you're welcome to bring libwww up to 5.2.8, if you want the job.