Subject: Python, minicom problems

From: [email-masked] (Paul Kautz)
Date: Wed, 12 Jun 1996 03:38:17 -0500 (EST)

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-masked]  Bom
"My Corn Cob God with the face up high without a motive startles."  Bim

---

From: Klee Dienes <[email-masked]>
Date: Wed, 12 Jun 1996 15:59:43 -0700

> [...] 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.  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.

---

From: [email-masked] (Paul Kautz)
Date: Wed, 12 Jun 1996 06:40:38 -0500 (EST)

> 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

---

From: Klee Dienes <[email-masked]>
Date: Wed, 12 Jun 1996 17:11:27 -0700

> 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.