Menu
▾
▴
#107 expect appears to be unmaintained
I'm helping a pkgsrc contributor update our package to 5.45.4 (yes, I know we're late doing that!). There are a number of minor issues, and pkgsrc norms require filing upstream bugs and listing the URL, so we avoid accumulating fixes that would benefit others and continue to need merging work.
Also, we add a pseudo-advisory "EOL" for packages that are no longer maintained, typically when branches are formally de-supported by their upstreams.
The most recent release is 2018, and there doesn't seem to be any maintainer activity in tickets since 2021, so it appears that maintenance of expect has ended. If that's so, it doesn't seem constructive to file bugs, and we should add an EOL notification.
Please let me know if my interpretation is correct. If not, I can avoid the EOL notification and file issues.
Hi,
This is unfortunately largely true - I will contact the tcl community and discuss the way forward - I have no time to work on expect any longer - and after a job switch no professional use for it. This makes my maintainer role less than ideal - I have a bunch of unreleased bug fixes though which I hope to push. Let me know if there's anything specific you're missing.
Also - with large scale refactoring ongoing for tcl 9 expect is in a difficult situation - it relies on internal TCL headers.
Cheers,
Nils
We have patches to add support for MirBSD and DragonFly, and now SCO/SVR5. The build system seems to do different things per platform (lib naming), and in pkgsrc that's a bug. There's no static lib and the dynamic lib doesn't have the normal naming (with a major/minor version). We have a workaround for deadlocks on solaris and linux. The code uses "open" as a procedure name which fails on SVR5 (and is dodgy anyway as shadowing is at best boggling). pkgsrc is stable, but these should be applied upstream, in a normal situation.
I have not dug in to operational things - this is just about making it build.
Some are at http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/tcl-expect/ and the SCO stuff will land in a few weeks after our quarterly freeze.
I'm not doing expect maintenance any more but I can offer some advice:
The reasons to include Tcl's internal headers were largely for the Tcl debugger (not an essential tool - can simply be deleted) and to use Expect as a standalone C library (skip it - it's not needed to run Expect).
Regarding the use of "open" as a function, Expect itself calls the system open(). Expect does not have its own open().
The GNU Toolchain (GCC, GDB, binutils) still relies heavily on expect for its various testsuites, so it would be a huge problem for the project if expect were to be EOL-ed...
FYI: the released version 5.45.4 of Expect does not work with the newly-released Tcl 9.0. There is a contributed port mentioned on the 9.0 porting page (https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9), which as of 2024-12 can be obtained from https://www.tcl3d.org/bawt/download/InputLibs/expect-5.45.4.1.7z
The porting page says that it doesn't work with GCC 14.x, but if you configure it with CFLAGS including
-fpermissive, it does.Anyone interested in maintainership is most welcome to take over. I'm unfortunately not a daily expect user for many years now and not dependent on it, so I'm really not suitable. Also my family has expanded since I took over and little free time is spent on programming these days!
Hi, I'm the maintainer of the expect package in OpenMandriva. While I don't have the time to take over maintainership of expect properly, I would certainly volunteer to get an expect 5.46 release out of the door that essentially does what we have in our package already: Tcl 9.0 support, support for newer compilers (without needing -fpermissive), and a few assorted bugfixes.
There is now a port of Expect to Tcl 9 at http://github.com/tcltk-depot/expect which houses a number of Tcl packages that are not longer maintained by the original authors.