On 8/16/2012 10:47, Aleksej Saushev wrote:
John Marino<netbsd%marino.st@localhost> writes:Of course, the fact that tcl83 packages exists weakens this thought.Have you ever tried updating it in practice? Reality is much harsher. You have to tweak many things anyway. "Completely backwards compatible" is a big stretch above, some rather important extensions were dropped.
When glib2 was updated, things broke. Bison 6.2 just broke some packages. Many examples of this, it goes with the territory. The question is who is responsible for the downstream breakage? The folks that updated those tools/libraries didn't fix downstream issues.
With the way TCL PLIST is set up, you can't have multiple versions of TCL installed. FreeBSD can, but the price is having no tcl headers at include/ and I think they must have man pages in a separate package.
So are you advocating having conflicting packages, having co-existing packages, or just updating the thing and deal with the carnage later?
I've got lang/tcl already building. I just released x11/tk is it's partner and needs to be updated at the same time. I'll happily post both packages so people can review/test prior to committing them.No. Don't do that. The primary reason why update wasn't done two years ago is that it requires rather large orchestrated effort.
My interpretation of this sentence is: Don't ask for review or testing, just commit it. Or alternatively: Because it requires a large effort, don't do anything and keep 8.4.x.
I have another historical question.This thing is built with libtool, which causes large patches of configure/.in, Makefile.in, tcl.m4, etc. FreeBSD uses the provided makefiles (lightly patched) and provide similar PLIST without libtool.
My question is: Is there a real reason that libtool is used here? Or alternatively: What problems occur if tcl and tk are built without libtool? Without libtool has the obvious benefit of easier upgrades in the future.
John