Re: Python, minicom problems
I ran into this problem again today; python requires tk40 and tcl74, which is fine if you want to use tkinter, but I don't, at this point. I would try to appease it, but unfortunately I only have tk41 and tcl75. [...] but it would be nicer if there was some system that could disable/enable features in packages. [...] The other solution is to just have a bunch of different python packages for whatever system, but that's not as Neat. The latest revision of the python package splits off all the non-core features into dynamically loadable modules that are available as separate packages. I've been holding off on uploading it until after the 1.1 release for fear of breaking things with the packaging changes. With regard to your other point (about disabling/enabling features in packages), I'd argue that the existing packaging system works just fine for that sort of thing, and that all we need are better tools for managing collections of sub-packages as a group, somewhat akin to the hierarchy of checkboxes you get when you install software on Windows or Machintosh machines. But then again talk is cheap unless I somehow find time to implement something like that for debian.
Re: Python, minicom problems
[...] but it would be nicer if there was some system that could disable/enable features in packages. [...] The latest revision of the python package splits off all the non-core features into dynamically loadable modules that are available as separate packages. Well, that sounds about like what I described! Excellent. This sounds like a good strategy to popularize. BTW, do you have a thread module for the new pthreads support? Paul Paul Kautz, Jumbo Yaffa Blocks #94: [ ] Avast Bim 1996 is the year of the accordion. [EMAIL PROTECTED] Bom My Corn Cob God with the face up high without a motive startles. Bim
Re: Python, minicom problems
BTW, do you have a thread module for the new pthreads support? Didn't know it existed. Send me a pointer and I'll include it in the next release.
Python, minicom problems
Some packages seem to 'require' things they shouldn't need. For example, gnuplot can run (believe it or not, I've used this) with a terminal of 'dumb,' outputting text graphs etc., but needs xlib. I solved this last time by just installing xlib, even though I wasn't running X. I ran into this problem again today; python requires tk40 and tcl74, which is fine if you want to use tkinter, but I don't, at this point. I would try to appease it, but unfortunately I only have tk41 and tcl75. What I'll probably do is go to a networked machine and put tk40 and tcl75 on disk, but it would be nicer if there was some system that could disable/enable features in packages. I am reminded of this by the recent announcement of libc5 with support for pthreads; it would be fun to try a threaded python, but wouldn't make much sense if you didn't have the pthreads kernal module installed. The other solution is to just have a bunch of different python packages for whatever system, but that's not as Neat. In other news, minicom consistantly fails to install: dpkg (subprocess): unable to execute new pre-installation script: No such file or directory And modconf always dies in the 'net' section (I had this machine networked to get what I thought I needed, then taken off). It took me awhile sans man to find that I needed to change conf.modules and /etc/modules. No, I don't know why it dies; it just waits a really long time looking for modules, and then returns to the previous menu. When I looked closely once, I saw a 'Segmentation Fault' for a moment, but I haven't been able to reproduce this. But I'm certainly glad to finally have linux at home; if I can just figure out anything about this monitor, I could give X a try... but that's another story. Thanks for your time, Paul Paul Kautz, Jumbo Yaffa Blocks #94: [ ] Avast Bim 1996 is the year of the accordion. [EMAIL PROTECTED] Bom My Corn Cob God with the face up high without a motive startles. Bim
Python, minicom problems
Paul Kautz: Some packages seem to 'require' things they shouldn't need. For example, gnuplot can run (believe it or not, I've used this) with a terminal of 'dumb,' outputting text graphs etc., but needs xlib. I solved this last time by just installing xlib, even though I wasn't running X. This is a consequence of the way that shared libraries are currently implemented by the standard startup code that comes with gcc. HJLu has written a rather nice document describing the underlying mechanisms -- I think that it should be possible to develop an alternative strategy that lets you test for the presence of a library at the time that you run into the first system call into that library. The biggest issue would be deciding how to tell the compiler which libraries should be given this special treatment. I'm a little uncertain that the obvious solution (do it for all shared libraries, or do it for none) will always do the right thing for libc. Followups to this message should go to debian-devel (or maybe linux-gcc@vger.rutgers.edu). -- Raul
