Debian bug report logs - #421
unreasonable restriction on term
Package: term; Reported by: Raul Miller <rdr@merit.edu>; 260 days old.
Message received at debian-bugs:
From irz301.inf.tu-dresden.de!sr1 Tue Sep 19 05:32:58 1995
Return-Path: <sr1@irz301.inf.tu-dresden.de>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0sv1r7-00063ZC; Tue, 19 Sep 95 05:32 PDT
Received: from irz101.inf.tu-dresden.de by pixar.com with SMTP id AA12768
(5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Tue, 19 Sep 1995 05:32:35 -0700
Received: by irz101.inf.tu-dresden.de (8.6.12/8.6.12-s1) id OAA29148; Tue, 19 Sep 1995 14:31:41 +0200
Date: Tue, 19 Sep 1995 14:31:41 +0200
From: sr1@irz301.inf.tu-dresden.de (Sven Rudolph)
Message-Id: <199509191231.OAA29148@irz101.inf.tu-dresden.de>
To: debian-bugs@pixar.com
Cc: jimr@simons-rock.edu
X-Debian-Pr: quiet
Subject: Re: Bug#421: unreasonable restriction on term
You already changed the DEPENDS to RECOMMENDED, so the problem is
solved and you should close the bug.
(It might make sense to invent a name for a dialer virtual package, but
you have to ask debian-devel about it.)
Please write me if you believe that I got somthing wrong.
Sven
--
Sven Rudolph (sr1@inf.tu-dresden.de); WWW : http://www.sax.de/~sr1/
Acknowledgement sent to sr1@irz301.inf.tu-dresden.de (Sven Rudolph):
Extra info received and filed, but not forwarded.
Full text available.
Bug assigned to package `term'.
Request was from iwj10@thor.cam.ac.uk (Ian Jackson)
to debian-bugs-request@pixar.com.
Full text available.
Message received at debian-bugs:
From cus.cam.ac.uk!iwj10 Sat Feb 18 08:32:04 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rfs4h-0002DDC; Sat, 18 Feb 95 08:32 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA03324
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Sat, 18 Feb 1995 08:32:35 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0rfs4W-000BzgC; Sat, 18 Feb 95 16:31 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0rfYcI-0002g8Z; Fri, 17 Feb 95 19:45 GMT
Message-Id: <m0rfYcI-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Fri, 17 Feb 95 19:45 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
References: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
Bill Mitchell writes ("Re: Bug#421: unreasonable restriction on term"):
> iwj10@cus.cam.ac.uk (Ian Jackson) said:
> > [...] dselect will
> > not invoke dpkg with any --force options, so anyone who has to work
> > around bad DEPENDS (and CONFLICTS) lines will have to install things
> > manually.
>
> Arguably a good thing, if dselect intended primarily as a tool for
> novices. [...]
Well, quite. However, there are quite a few things that dselect will
be able to do that dpkg can't - mainly the automatic management of the
selection/installation/deinstallation process.
I don't expect most users - even experts - to have to be familiar with
dpkg once dselect works correctly. They may even be unaware of its
existence ...
Ian.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0rfYcI-0002g8Z.ijackson@nyx.cs.du.edu>
References: <m0rfYcI-0002g8Z.ijackson@nyx.cs.du.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: iwj10@cus.cam.ac.uk (Ian Jackson), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: iwj10@cus.cam.ac.uk (Ian Jackson)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Sat, 18 Feb 1995 16:48:04 GMT
Resent-Message-ID: <debian-bugs-handler.421.02181633158699@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Sat, 18 Feb 1995 16:48:04 GMT
Received: with rfc822 via encapsulated-mail id 02181633158699;
Sat, 18 Feb 1995 16:33:16 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rfs4h-0002DDC; Sat, 18 Feb 95 08:32 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA03324
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Sat, 18 Feb 1995 08:32:35 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0rfs4W-000BzgC; Sat, 18 Feb 95 16:31 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0rfYcI-0002g8Z; Fri, 17 Feb 95 19:45 GMT
Message-Id: <m0rfYcI-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Fri, 17 Feb 95 19:45 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
In-Reply-To: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
References: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
Bill Mitchell writes ("Re: Bug#421: unreasonable restriction on term"):
> iwj10@cus.cam.ac.uk (Ian Jackson) said:
> > [...] dselect will
> > not invoke dpkg with any --force options, so anyone who has to work
> > around bad DEPENDS (and CONFLICTS) lines will have to install things
> > manually.
>
> Arguably a good thing, if dselect intended primarily as a tool for
> novices. [...]
Well, quite. However, there are quite a few things that dselect will
be able to do that dpkg can't - mainly the automatic management of the
selection/installation/deinstallation process.
I don't expect most users - even experts - to have to be familiar with
dpkg once dselect works correctly. They may even be unaware of its
existence ...
Ian.
Message received at debian-bugs:
From mdd.comm.mot.com!mitchell Fri Feb 17 06:33:23 1995
Return-Path: <mitchell@mdd.comm.mot.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rfTkH-0005syC; Fri, 17 Feb 95 06:33 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA14262
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Fri, 17 Feb 1995 06:33:54 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA27830; Fri, 17 Feb 1995 08:31:35 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1)
id AA10127; Fri, 17 Feb 1995 08:31:13 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA02386; Fri, 17 Feb 95 06:31:06 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA13891; Fri, 17 Feb 95 06:30:57 PST
Date: Fri, 17 Feb 95 06:30:57 PST
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Message-Id: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
To: debian-bugs@pixar.com, iwj10@cus.cam.ac.uk
Subject: Re: Bug#421: unreasonable restriction on term
iwj10@cus.cam.ac.uk (Ian Jackson) said:
> [...] dselect will
> not invoke dpkg with any --force options, so anyone who has to work
> around bad DEPENDS (and CONFLICTS) lines will have to install things
> manually.
Arguably a good thing, if dselect intended primarily as a tool for
novices. The approach is similar to putting the scissors out of reach
because a child might hurt himself if allowed to get hold of them.
Those who aren't novices (anyone tall enough) can use the dpkg
command-line interface.
Sort of like front-ending rm(1) with del(1L), which might refuse to
remove unwritable files instead of asking for confirmation first.
Anyone tall enough that he's outgrown del can use rm. Those not
tall enough, but who have heard of rm, can stand on a box to get at it.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: mitchell@mdd.comm.mot.com (Bill Mitchell)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
References: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Fri, 17 Feb 1995 14:48:04 GMT
Resent-Message-ID: <debian-bugs-handler.421.021714433616234@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Fri, 17 Feb 1995 14:48:04 GMT
Received: with rfc822 via encapsulated-mail id 021714433616234;
Fri, 17 Feb 1995 14:43:37 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rfTkH-0005syC; Fri, 17 Feb 95 06:33 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA14262
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Fri, 17 Feb 1995 06:33:54 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA27830; Fri, 17 Feb 1995 08:31:35 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1)
id AA10127; Fri, 17 Feb 1995 08:31:13 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA02386; Fri, 17 Feb 95 06:31:06 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA13891; Fri, 17 Feb 95 06:30:57 PST
Date: Fri, 17 Feb 95 06:30:57 PST
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Message-Id: <9502171430.AA13891@bb29c.mdd.comm.mot.com>
To: debian-bugs@pixar.com, iwj10@cus.cam.ac.uk
iwj10@cus.cam.ac.uk (Ian Jackson) said:
> [...] dselect will
> not invoke dpkg with any --force options, so anyone who has to work
> around bad DEPENDS (and CONFLICTS) lines will have to install things
> manually.
Arguably a good thing, if dselect intended primarily as a tool for
novices. The approach is similar to putting the scissors out of reach
because a child might hurt himself if allowed to get hold of them.
Those who aren't novices (anyone tall enough) can use the dpkg
command-line interface.
Sort of like front-ending rm(1) with del(1L), which might refuse to
remove unwritable files instead of asking for confirmation first.
Anyone tall enough that he's outgrown del can use rm. Those not
tall enough, but who have heard of rm, can stand on a box to get at it.
Message received at debian-bugs:
From cus.cam.ac.uk!iwj10 Thu Feb 16 07:12:40 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rf7sk-0006WPC; Thu, 16 Feb 95 07:12 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA01986
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Thu, 16 Feb 1995 07:13:05 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0rf7sH-000C0FC; Thu, 16 Feb 95 15:12 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0rf6cd-0002g8Z; Thu, 16 Feb 95 13:51 GMT
Message-Id: <m0rf6cd-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Thu, 16 Feb 95 13:51 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
References: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
<m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
<m0rebjK-00001eC@plato.simons-rock.edu>
<mitchell@mdd.comm.mot.com>
Bill Mitchell writes ("Re: Bug#421: unreasonable restriction on term"):
> On Tue, 14 Feb 1995, Ian Jackson wrote:
> > Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> > > [... new dpkg's capability to force installation despite not being
> > > able to satisfy DEPENDS field requirements ...]
> >
> > I had a bad feeling when I put in that option that people might use it
> > for this kind of thing.
> >
> > The ONLY REASON people should have to use the --force-<thing> options
> > in dpkg is to work around some kind of brokenness - either in dpkg
> > itself or in a package.
>
> I'm not sure that's the ONLY reason. One other reason might be,
> for example, for a user to install the term.deb package when he
> has a comm package not "blessed" by the term maintainer by being
> included among the alternatives listed on the DEPENDS control-file
> line.
This reminds me of Raul Miller's comment that by using a Depends line
the term maintainer is making a commitment to track all of the comms
packages available ...
> This might be a comm package installed by dpkg from a package.deb
> file, but which hasn't (yet?) been picked up in term.deb as a
> "blessed" alternative dependency. It might also be a comm package
> installed from sources other than a pkg.deb file, and not through
> the services of dpkg.
Indeed.
> One other way around this would be for the user to install one
> of the "blessed" comm packages to satisfy dpkg and convince it to
> allow the installation of term.deb, then to remove the unwanted
> comm package which had been installed for the sole purpose of
> tricking dpkg. (That is, possibly, until dpkg gets smart enough
> to refuse to remove packages which still have dependent packages
> installed.)
dpkg is already that smart - I'm afraid that ruse won't work.
> [...]
> When push comes to shove, the bottom line is that DEPENDS will have
> whatever the package maintainer decides to put there, and that might
> not be a good fit with the needs of 100.00% of all installers. In
> those cases where the fit is bad, and if the user is sufficiently
> clued-in to what its real import is, the dpkg --force option
> provides one way around this sort of a bad fit.
No, it doesn't provide a real solution. For one thing, dselect will
not invoke dpkg with any --force options, so anyone who has to work
around bad DEPENDS (and CONFLICTS) lines will have to install things
manually.
James A. Robinson writes ("Re: Bug#421: unreasonable restriction on term "):
> [...]
> As long as there is some very definite message to the new user,
> regardless of how they do the install, that it is a VERY good idea to
> install a comm package with term, I am willing to do what Raul wants.
> Since Ian says that dinstall will say this for sure, I am willing to
> change the DEPENDS to RECOMMENDED. I would rather wait until we
> actually are distributing a dinstall though, since I want to see its
> output.
I think you mean dselect rather than dinstall ...
dselect will, if you select a package and haven't got any of its
Recommended's installed, bring up a new package selection list with
just the Recommended's listed and will by default select one of them
for the user.
There'll be a warning if they choose to override a Recommended or
Depends line at this stage. (dselect doesn't enforce Depends, dpkg
does, so users will be able to select things that dselect things are
impossible in the hope that when the actual *.deb files are fed to
dpkg things will work.)
When the new C dpkg is available (after I've done with dselect) it
will warn about unsatisfied Recommended fields. The current dpkg
doesn't.
So, with our current installation tools there won't be the warning you
are looking for. However, I think that introducing brokenness in a
package to get around brokenness in the packaging tools is a bad thing
- the missing functionality will just have to be accepted as missing.
Ian.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0rf6cd-0002g8Z.ijackson@nyx.cs.du.edu>
References: <m0rf6cd-0002g8Z.ijackson@nyx.cs.du.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: iwj10@cus.cam.ac.uk (Ian Jackson), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: iwj10@cus.cam.ac.uk (Ian Jackson)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Thu, 16 Feb 1995 15:18:07 GMT
Resent-Message-ID: <debian-bugs-handler.421.02161514533015@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Thu, 16 Feb 1995 15:18:07 GMT
Received: with rfc822 via encapsulated-mail id 02161514533015;
Thu, 16 Feb 1995 15:14:54 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rf7sk-0006WPC; Thu, 16 Feb 95 07:12 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA01986
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Thu, 16 Feb 1995 07:13:05 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0rf7sH-000C0FC; Thu, 16 Feb 95 15:12 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0rf6cd-0002g8Z; Thu, 16 Feb 95 13:51 GMT
Message-Id: <m0rf6cd-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Thu, 16 Feb 95 13:51 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
In-Reply-To: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
References: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
<m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
<m0rebjK-00001eC@plato.simons-rock.edu>
<mitchell@mdd.comm.mot.com>
Bill Mitchell writes ("Re: Bug#421: unreasonable restriction on term"):
> On Tue, 14 Feb 1995, Ian Jackson wrote:
> > Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> > > [... new dpkg's capability to force installation despite not being
> > > able to satisfy DEPENDS field requirements ...]
> >
> > I had a bad feeling when I put in that option that people might use it
> > for this kind of thing.
> >
> > The ONLY REASON people should have to use the --force-<thing> options
> > in dpkg is to work around some kind of brokenness - either in dpkg
> > itself or in a package.
>
> I'm not sure that's the ONLY reason. One other reason might be,
> for example, for a user to install the term.deb package when he
> has a comm package not "blessed" by the term maintainer by being
> included among the alternatives listed on the DEPENDS control-file
> line.
This reminds me of Raul Miller's comment that by using a Depends line
the term maintainer is making a commitment to track all of the comms
packages available ...
> This might be a comm package installed by dpkg from a package.deb
> file, but which hasn't (yet?) been picked up in term.deb as a
> "blessed" alternative dependency. It might also be a comm package
> installed from sources other than a pkg.deb file, and not through
> the services of dpkg.
Indeed.
> One other way around this would be for the user to install one
> of the "blessed" comm packages to satisfy dpkg and convince it to
> allow the installation of term.deb, then to remove the unwanted
> comm package which had been installed for the sole purpose of
> tricking dpkg. (That is, possibly, until dpkg gets smart enough
> to refuse to remove packages which still have dependent packages
> installed.)
dpkg is already that smart - I'm afraid that ruse won't work.
> [...]
> When push comes to shove, the bottom line is that DEPENDS will have
> whatever the package maintainer decides to put there, and that might
> not be a good fit with the needs of 100.00% of all installers. In
> those cases where the fit is bad, and if the user is sufficiently
> clued-in to what its real import is, the dpkg --force option
> provides one way around this sort of a bad fit.
No, it doesn't provide a real solution. For one thing, dselect will
not invoke dpkg with any --force options, so anyone who has to work
around bad DEPENDS (and CONFLICTS) lines will have to install things
manually.
James A. Robinson writes ("Re: Bug#421: unreasonable restriction on term "):
> [...]
> As long as there is some very definite message to the new user,
> regardless of how they do the install, that it is a VERY good idea to
> install a comm package with term, I am willing to do what Raul wants.
> Since Ian says that dinstall will say this for sure, I am willing to
> change the DEPENDS to RECOMMENDED. I would rather wait until we
> actually are distributing a dinstall though, since I want to see its
> output.
I think you mean dselect rather than dinstall ...
dselect will, if you select a package and haven't got any of its
Recommended's installed, bring up a new package selection list with
just the Recommended's listed and will by default select one of them
for the user.
There'll be a warning if they choose to override a Recommended or
Depends line at this stage. (dselect doesn't enforce Depends, dpkg
does, so users will be able to select things that dselect things are
impossible in the hope that when the actual *.deb files are fed to
dpkg things will work.)
When the new C dpkg is available (after I've done with dselect) it
will warn about unsatisfied Recommended fields. The current dpkg
doesn't.
So, with our current installation tools there won't be the warning you
are looking for. However, I think that introducing brokenness in a
package to get around brokenness in the packaging tools is a bad thing
- the missing functionality will just have to be accepted as missing.
Ian.
Message received at debian-bugs:
From legislate.com!rdr Wed Feb 15 07:42:35 1995
Return-Path: <rdr@legislate.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rels8-0005syC; Wed, 15 Feb 95 07:42 PST
Received: from [192.77.155.4] by pixar.com with SMTP id AA19445
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Wed, 15 Feb 1995 07:43:04 -0800
Received: by [192.77.155.4]
id m0rehDE-000HpUC
(Debian /\oo/\ Smail3.1.29.1 #29.24); Wed, 15 Feb 95 05:44 EST
Message-Id: <m0rehDE-000HpUC@[192.77.155.4]>
Date: Wed, 15 Feb 95 05:44 EST
From: rdr@legislate.com (Raul D. Miller)
To: jimr@simons-rock.edu
Cc: debian-bugs@pixar.com
In-Reply-To: <m0reWZu-00001TC@plato.simons-rock.edu> (jimr@simons-rock.edu)
Subject: Re: Bug#421: unreasonable restriction on term
[Note: I don't want this to come off as a flame, because these are serious
concerns I have.]
My fragile ego shall take note :-)
> Sure, and it takes about five minutes to write a primitive (no
> scripting language) terminal emulator for Linux. So, it should
> be trivial to come up with one tailored to the requirements of
> term, which could be supplied with term. Would that be adequate?
But your program is going to have to handle allowing the user to
login to their host system (7bit or 8bit line), allow them enough
of an interface to upload a copy of term source, or term setup
files, and work on them.
Hmm.. 7 vs. 8 bit can be dealt with using stty on the serial line.
But, getting term to the remote side isn't a job for a cheap terminal
emulator. On the other hand, if the remote side is well connected
(which is the whole point of using term in the first place) it will
probably be possible to ftp a copy of the source from some well known
site. E.g. you could have a term-aid kit in some documented place in
the debian archive file structure.
Your also going to have to make sure it can easily deal with
multiple phone numbers (for people with accounts on different
machines), modem problems (BUSY signals, etc.), and probably some
things I am forgetting.
I was envisioning the person handling this manually. For automatic
handling, it's probably better to get a package like diald. No?
This is all going to have to be bundled into a package that is easy
to setup and use. This seems like a job for a comm program that is
standard (documented, and well supported) and debian-packaged for
easy installation and setup.
I'm not knocking kermit|minicom|seyon as good to use packages. I
wouldn't have even noticed the requirement in my current configuration
except that none of these are currently available in the debian 0.93
distribution.
I didn't like the idea of changing it to RECOMMENDED, because I am
sure some people who *don't* know what they are doing will sluff it
off, and then complain that Debian Term [favorite expletive(s)]
because they can't set it up on their remote end. This is a pretty
dim view of the end user, but I happen to believe that the lowest
common denominator is what we need to accommodate.
Er... um... I thought you said that it took a significant amount of
reading the docs and such to get term working? As long as it's all
documented in one place, it's ultimately up to the user.
If you are willing to make a comm program that is tailored to term,
and does what I list above, I will be more then willing to bundle
it with term. (In fact, it would be something to send to the
current term author/maintainer, call it tdial or soemthing...)
Unfortunately, I'm not going to be able to test term -- I don't have a
modem.
[I've been wondering about the possibility of using term to provide ip
services on a machine that's in DNS -- tunnelling from my machine to
one of the other machines were I have small shell accounts. But even
if I pursued that avenue I wouldn't have a system which allows me to
do reasonable testing. So the best I can do at the moment is offer
hints, suggestions, and sample code.]
[Also my idea of user friendliness is probably a bit different from
most peoples. To my mind, ATDT<phone-number> is more user friendly
than "locate whatever dialing menu this comm package has and try and
figure out how to enter it, then try and figure out how to get it to
send it to the modem, and then try and figure out what else it's doing
that it's not telling me about".]
Um... there's a lot of communications packages out there. For
example, uucp has cu, which does lots of wonderful automated things
and just needs a good HOWTO to document various basic configuration
techniques. Ultimately, by having a REQUIRES: which ennumerates
various communications packages, you're documenting that you intend to
proactively track the packages which are out there and update the
package every time a good alternative appears. Aside from this
current "what is good?" discussion, this sounds like a lot of work
(shudder).
Anyways, if my vision of a minimal user interface (documented shell
commands) doesn't align with your vision of term, I'll bow to your
better knowledge of the kind of thing that term does.
Raul D. Miller
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: rdr@legislate.com (Raul D. Miller)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0rehDE-000HpUC@[192.77.155.4]>
References: <m0rehDE-000HpUC@[192.77.155.4]>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: rdr@legislate.com (Raul D. Miller), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: rdr@legislate.com (Raul D. Miller)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Wed, 15 Feb 1995 16:03:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.02151548075552@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Wed, 15 Feb 1995 16:03:01 GMT
Received: with rfc822 via encapsulated-mail id 02151548075552;
Wed, 15 Feb 1995 15:48:07 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rels8-0005syC; Wed, 15 Feb 95 07:42 PST
Received: from [192.77.155.4] by pixar.com with SMTP id AA19445
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Wed, 15 Feb 1995 07:43:04 -0800
Received: by [192.77.155.4]
id m0rehDE-000HpUC
(Debian /\oo/\ Smail3.1.29.1 #29.24); Wed, 15 Feb 95 05:44 EST
Message-Id: <m0rehDE-000HpUC@[192.77.155.4]>
Date: Wed, 15 Feb 95 05:44 EST
From: rdr@legislate.com (Raul D. Miller)
To: jimr@simons-rock.edu
Cc: debian-bugs@pixar.com
In-Reply-To: <m0reWZu-00001TC@plato.simons-rock.edu> (jimr@simons-rock.edu)
[Note: I don't want this to come off as a flame, because these are serious
concerns I have.]
My fragile ego shall take note :-)
> Sure, and it takes about five minutes to write a primitive (no
> scripting language) terminal emulator for Linux. So, it should
> be trivial to come up with one tailored to the requirements of
> term, which could be supplied with term. Would that be adequate?
But your program is going to have to handle allowing the user to
login to their host system (7bit or 8bit line), allow them enough
of an interface to upload a copy of term source, or term setup
files, and work on them.
Hmm.. 7 vs. 8 bit can be dealt with using stty on the serial line.
But, getting term to the remote side isn't a job for a cheap terminal
emulator. On the other hand, if the remote side is well connected
(which is the whole point of using term in the first place) it will
probably be possible to ftp a copy of the source from some well known
site. E.g. you could have a term-aid kit in some documented place in
the debian archive file structure.
Your also going to have to make sure it can easily deal with
multiple phone numbers (for people with accounts on different
machines), modem problems (BUSY signals, etc.), and probably some
things I am forgetting.
I was envisioning the person handling this manually. For automatic
handling, it's probably better to get a package like diald. No?
This is all going to have to be bundled into a package that is easy
to setup and use. This seems like a job for a comm program that is
standard (documented, and well supported) and debian-packaged for
easy installation and setup.
I'm not knocking kermit|minicom|seyon as good to use packages. I
wouldn't have even noticed the requirement in my current configuration
except that none of these are currently available in the debian 0.93
distribution.
I didn't like the idea of changing it to RECOMMENDED, because I am
sure some people who *don't* know what they are doing will sluff it
off, and then complain that Debian Term [favorite expletive(s)]
because they can't set it up on their remote end. This is a pretty
dim view of the end user, but I happen to believe that the lowest
common denominator is what we need to accommodate.
Er... um... I thought you said that it took a significant amount of
reading the docs and such to get term working? As long as it's all
documented in one place, it's ultimately up to the user.
If you are willing to make a comm program that is tailored to term,
and does what I list above, I will be more then willing to bundle
it with term. (In fact, it would be something to send to the
current term author/maintainer, call it tdial or soemthing...)
Unfortunately, I'm not going to be able to test term -- I don't have a
modem.
[I've been wondering about the possibility of using term to provide ip
services on a machine that's in DNS -- tunnelling from my machine to
one of the other machines were I have small shell accounts. But even
if I pursued that avenue I wouldn't have a system which allows me to
do reasonable testing. So the best I can do at the moment is offer
hints, suggestions, and sample code.]
[Also my idea of user friendliness is probably a bit different from
most peoples. To my mind, ATDT<phone-number> is more user friendly
than "locate whatever dialing menu this comm package has and try and
figure out how to enter it, then try and figure out how to get it to
send it to the modem, and then try and figure out what else it's doing
that it's not telling me about".]
Um... there's a lot of communications packages out there. For
example, uucp has cu, which does lots of wonderful automated things
and just needs a good HOWTO to document various basic configuration
techniques. Ultimately, by having a REQUIRES: which ennumerates
various communications packages, you're documenting that you intend to
proactively track the packages which are out there and update the
package every time a good alternative appears. Aside from this
current "what is good?" discussion, this sounds like a lot of work
(shudder).
Anyways, if my vision of a minimal user interface (documented shell
commands) doesn't align with your vision of term, I'll bow to your
better knowledge of the kind of thing that term does.
Raul D. Miller
Message received at debian-bugs:
From simons-rock.edu!jimr Tue Feb 14 20:53:31 1995
Return-Path: <jimr@simons-rock.edu>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rebk1-0006dfC; Tue, 14 Feb 95 20:53 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA19404
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 20:54:02 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0rebjK-00001eC; Tue, 14 Feb 95 23:52 EST
Message-Id: <m0rebjK-00001eC@plato.simons-rock.edu>
To: Bill Mitchell <mitchell@mdd.comm.mot.com>, debian-bugs@pixar.com
Cc: Ian Jackson <iwj10@cus.cam.ac.uk>
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: Message from Bill Mitchell <mitchell@mdd.comm.mot.com>
of "Tue, 14 Feb 1995 19:23:19 PST." <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
Date: Tue, 14 Feb 1995 23:52:46 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
>
> This might be a comm package installed by dpkg from a package.deb
> file, but which hasn't (yet?) been picked up in term.deb as a
> "blessed" alternative dependency. It might also be a comm package
> installed from sources other than a pkg.deb file, and not through
> the services of dpkg.
[....]
> Ian goes on to opine that the DEPENDS entries for term should be
> recast as RECOMMENDED. There's a debate on that point currently
> in progress, with the term package maintainer so far steadfastly
> maintaining that he'll not back off the DEPENDS category without
> assurance that some satisfactorily-functional phone interface and
> comm package wil be available.
As long as there is some very definite message to the new user,
regardless of how they do the install, that it is a VERY good idea to
install a comm package with term, I am willing to do what Raul wants.
Since Ian says that dinstall will say this for sure, I am willing to
change the DEPENDS to RECOMMENDED. I would rather wait until we
actually are distributing a dinstall though, since I want to see its
output.
Jim
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: "James A. Robinson" <jimr@simons-rock.edu>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0rebjK-00001eC@plato.simons-rock.edu>
References: <m0rebjK-00001eC@plato.simons-rock.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: "James A. Robinson" <jimr@simons-rock.edu>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: "James A. Robinson" <jimr@simons-rock.edu>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Wed, 15 Feb 1995 05:03:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.02150454399700@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Wed, 15 Feb 1995 05:03:01 GMT
Received: with rfc822 via encapsulated-mail id 02150454399700;
Wed, 15 Feb 1995 04:54:39 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0rebk1-0006dfC; Tue, 14 Feb 95 20:53 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA19404
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 20:54:02 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0rebjK-00001eC; Tue, 14 Feb 95 23:52 EST
Message-Id: <m0rebjK-00001eC@plato.simons-rock.edu>
To: Bill Mitchell <mitchell@mdd.comm.mot.com>, debian-bugs@pixar.com
Cc: Ian Jackson <iwj10@cus.cam.ac.uk>
In-Reply-To: Message from Bill Mitchell <mitchell@mdd.comm.mot.com>
of "Tue, 14 Feb 1995 19:23:19 PST." <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
Date: Tue, 14 Feb 1995 23:52:46 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
>
> This might be a comm package installed by dpkg from a package.deb
> file, but which hasn't (yet?) been picked up in term.deb as a
> "blessed" alternative dependency. It might also be a comm package
> installed from sources other than a pkg.deb file, and not through
> the services of dpkg.
[....]
> Ian goes on to opine that the DEPENDS entries for term should be
> recast as RECOMMENDED. There's a debate on that point currently
> in progress, with the term package maintainer so far steadfastly
> maintaining that he'll not back off the DEPENDS category without
> assurance that some satisfactorily-functional phone interface and
> comm package wil be available.
As long as there is some very definite message to the new user,
regardless of how they do the install, that it is a VERY good idea to
install a comm package with term, I am willing to do what Raul wants.
Since Ian says that dinstall will say this for sure, I am willing to
change the DEPENDS to RECOMMENDED. I would rather wait until we
actually are distributing a dinstall though, since I want to see its
output.
Jim
Message received at debian-bugs:
From mdd.comm.mot.com!mitchell Tue Feb 14 19:51:24 1995
Return-Path: <mitchell@mdd.comm.mot.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0realu-0005rBC; Tue, 14 Feb 95 19:51 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA15842
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 19:25:08 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA28694; Tue, 14 Feb 1995 21:23:31 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1)
id AA21598; Tue, 14 Feb 1995 21:23:29 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA17963; Tue, 14 Feb 95 19:23:23 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA28013; Tue, 14 Feb 95 19:23:20 PST
Date: Tue, 14 Feb 1995 19:23:19 -0800 (PST)
From: Bill Mitchell <mitchell@mdd.comm.mot.com>
X-Sender: mitchell@bb29c
To: Ian Jackson <iwj10@cus.cam.ac.uk>, debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
Message-Id: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 14 Feb 1995, Ian Jackson wrote:
> Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> > [... new dpkg's capability to force installation despite not being
> > able to satisfy DEPENDS field requirements ...]
>
> I had a bad feeling when I put in that option that people might use it
> for this kind of thing.
>
> The ONLY REASON people should have to use the --force-<thing> options
> in dpkg is to work around some kind of brokenness - either in dpkg
> itself or in a package.
I'm not sure that's the ONLY reason. One other reason might be,
for example, for a user to install the term.deb package when he
has a comm package not "blessed" by the term maintainer by being
included among the alternatives listed on the DEPENDS control-file
line.
This might be a comm package installed by dpkg from a package.deb
file, but which hasn't (yet?) been picked up in term.deb as a
"blessed" alternative dependency. It might also be a comm package
installed from sources other than a pkg.deb file, and not through
the services of dpkg.
One other way around this would be for the user to install one
of the "blessed" comm packages to satisfy dpkg and convince it to
allow the installation of term.deb, then to remove the unwanted
comm package which had been installed for the sole purpose of
tricking dpkg. (That is, possibly, until dpkg gets smart enough
to refuse to remove packages which still have dependent packages
installed.)
Ian goes on to opine that the DEPENDS entries for term should be
recast as RECOMMENDED. There's a debate on that point currently
in progress, with the term package maintainer so far steadfastly
maintaining that he'll not back off the DEPENDS category without
assurance that some satisfactorily-functional phone interface and
comm package wil be available.
When push comes to shove, the bottom line is that DEPENDS will have
whatever the package maintainer decides to put there, and that might
not be a good fit with the needs of 100.00% of all installers. In
those cases where the fit is bad, and if the user is sufficiently
clued-in to what its real import is, the dpkg --force option
provides one way around this sort of a bad fit.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: Bill Mitchell <mitchell@mdd.comm.mot.com>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
References: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: Bill Mitchell <mitchell@mdd.comm.mot.com>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: Bill Mitchell <mitchell@mdd.comm.mot.com>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Wed, 15 Feb 1995 04:03:04 GMT
Resent-Message-ID: <debian-bugs-handler.421.02150352338073@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Wed, 15 Feb 1995 04:03:04 GMT
Received: with rfc822 via encapsulated-mail id 02150352338073;
Wed, 15 Feb 1995 03:52:34 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0realu-0005rBC; Tue, 14 Feb 95 19:51 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA15842
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 19:25:08 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA28694; Tue, 14 Feb 1995 21:23:31 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1)
id AA21598; Tue, 14 Feb 1995 21:23:29 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA17963; Tue, 14 Feb 95 19:23:23 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA28013; Tue, 14 Feb 95 19:23:20 PST
Date: Tue, 14 Feb 1995 19:23:19 -0800 (PST)
From: Bill Mitchell <mitchell@mdd.comm.mot.com>
X-Sender: mitchell@bb29c
To: Ian Jackson <iwj10@cus.cam.ac.uk>, debian-bugs@pixar.com
In-Reply-To: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
Message-Id: <Pine.SUN.3.90.950214184804.27991A-100000@bb29c>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 14 Feb 1995, Ian Jackson wrote:
> Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> > [... new dpkg's capability to force installation despite not being
> > able to satisfy DEPENDS field requirements ...]
>
> I had a bad feeling when I put in that option that people might use it
> for this kind of thing.
>
> The ONLY REASON people should have to use the --force-<thing> options
> in dpkg is to work around some kind of brokenness - either in dpkg
> itself or in a package.
I'm not sure that's the ONLY reason. One other reason might be,
for example, for a user to install the term.deb package when he
has a comm package not "blessed" by the term maintainer by being
included among the alternatives listed on the DEPENDS control-file
line.
This might be a comm package installed by dpkg from a package.deb
file, but which hasn't (yet?) been picked up in term.deb as a
"blessed" alternative dependency. It might also be a comm package
installed from sources other than a pkg.deb file, and not through
the services of dpkg.
One other way around this would be for the user to install one
of the "blessed" comm packages to satisfy dpkg and convince it to
allow the installation of term.deb, then to remove the unwanted
comm package which had been installed for the sole purpose of
tricking dpkg. (That is, possibly, until dpkg gets smart enough
to refuse to remove packages which still have dependent packages
installed.)
Ian goes on to opine that the DEPENDS entries for term should be
recast as RECOMMENDED. There's a debate on that point currently
in progress, with the term package maintainer so far steadfastly
maintaining that he'll not back off the DEPENDS category without
assurance that some satisfactorily-functional phone interface and
comm package wil be available.
When push comes to shove, the bottom line is that DEPENDS will have
whatever the package maintainer decides to put there, and that might
not be a good fit with the needs of 100.00% of all installers. In
those cases where the fit is bad, and if the user is sufficiently
clued-in to what its real import is, the dpkg --force option
provides one way around this sort of a bad fit.
Message received at debian-bugs:
From cus.cam.ac.uk!iwj10 Tue Feb 14 18:16:09 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reZHl-0005jrA; Tue, 14 Feb 95 18:16 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA12945
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 18:16:45 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reZHf-000BzzA; Wed, 15 Feb 95 02:16 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reZGD-0002g8A; Wed, 15 Feb 95 02:14 GMT
Message-Id: <m0reZGD-0002g8A.ijackson@nyx.cs.du.edu>
Date: Wed, 15 Feb 95 02:14 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
Precedence: air-mail
"James A. Robinson" writes ("Bug#421: unreasonable restriction on term"):
> [...]
> I didn't like the idea of changing it to RECOMMENDED, because I am
> sure some people who *don't* know what they are doing will sluff it
> off, and then complain that Debian Term [favorite expletive(s)]
> because they can't set it up on their remote end. This is a pretty
> dim view of the end user, but I happen to believe that the lowest
> common denominator is what we need to accommodate.
When dselect is available this will only be true if the user
deliberately ignored strong hints from dselect about what to do. I
could even have dpkg issue a warning.
Ian.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0reZGD-0002g8A.ijackson@nyx.cs.du.edu>
References: <m0reZGD-0002g8A.ijackson@nyx.cs.du.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: iwj10@cus.cam.ac.uk (Ian Jackson), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: iwj10@cus.cam.ac.uk (Ian Jackson)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Wed, 15 Feb 1995 02:18:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.02150217175177@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Wed, 15 Feb 1995 02:18:01 GMT
Received: with rfc822 via encapsulated-mail id 02150217175177;
Wed, 15 Feb 1995 02:17:17 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reZHl-0005jrA; Tue, 14 Feb 95 18:16 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA12945
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 18:16:45 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reZHf-000BzzA; Wed, 15 Feb 95 02:16 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reZGD-0002g8A; Wed, 15 Feb 95 02:14 GMT
Message-Id: <m0reZGD-0002g8A.ijackson@nyx.cs.du.edu>
Date: Wed, 15 Feb 95 02:14 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Precedence: air-mail
"James A. Robinson" writes ("Bug#421: unreasonable restriction on term"):
> [...]
> I didn't like the idea of changing it to RECOMMENDED, because I am
> sure some people who *don't* know what they are doing will sluff it
> off, and then complain that Debian Term [favorite expletive(s)]
> because they can't set it up on their remote end. This is a pretty
> dim view of the end user, but I happen to believe that the lowest
> common denominator is what we need to accommodate.
When dselect is available this will only be true if the user
deliberately ignored strong hints from dselect about what to do. I
could even have dpkg issue a warning.
Ian.
Message received at debian-bugs:
From cus.cam.ac.uk!iwj10 Tue Feb 14 15:58:17 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reX8L-0005fUC; Tue, 14 Feb 95 15:58 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA07152
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 15:58:50 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reWZu-000C0KC; Tue, 14 Feb 95 23:22 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reUra-0002g8Z; Tue, 14 Feb 95 21:32 GMT
Message-Id: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Tue, 14 Feb 95 21:32 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> [...]
> Sounds like a judgement call to me. After checking the Guidelines, I
> think I'd lean towards using the RECOMMEND field instead of DEPENDS
> if it were my judgement call. However, I might lean back in light
> of the new dpkg's capability (going from memory here, since I don't
> have it available just now) to force installation despite not being
> able to satisfy DEPENDS field requirements. That's an expert-user
> sort of option, but we're also talking an expert-user sort of
> situation in wanting to install the term package without a comm
> programm which has been blessed by the term package maintainer.
I had a bad feeling when I put in that option that people might use it
for this kind of thing.
The ONLY REASON people should have to use the --force-<thing> options
in dpkg is to work around some kind of brokenness - either in dpkg
itself or in a package.
Therefore, by definition, requiring the user to say --force-depends
when doing something perfectly reasonable is broken.
Just because these options and facilities exist doesn't mean we should
arrange to make use of them.
Furthermore, the future effects of using --force-depends are rather
unpredictable. In some cases it will be necessary to say
--force-depends on removals of other not-very-related packages, for
example.
>From the Guidelines quote (which I wrote, btw):
+ The DEPENDS field lists packages that are required for this package to
+ provide a significant amount of functionality. The package
+ maintenance software will not allow a package to be installed without
+ also installing packages listed in its DEPENDS field, and will run the
+ postinst scripts of packages listed in DEPENDS fields before those of
+ the packages which depend on them, and run the prerm scripts before.
It is clear that term can provide a significant amount of
functionality without any of the packages that are currently listed in
its DEPENDS field. Package maintainers should read `will not allow'
literally, and not rely on features like --force-*.
+ The RECOMMENDED field lists packages that would be found together with
+ this one in all but unusual installations. The package maintenance
+ software will warn the user if they install a package without those
+ listed in its RECOMMENDED field.
This is the appropriate level of dependency. It is the one that (for
example) the X server and X client software should mutually use.
Ian.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
References: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: iwj10@cus.cam.ac.uk (Ian Jackson), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: iwj10@cus.cam.ac.uk (Ian Jackson)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Wed, 15 Feb 1995 00:03:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.021423592527013@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Wed, 15 Feb 1995 00:03:01 GMT
Received: with rfc822 via encapsulated-mail id 021423592527013;
Tue, 14 Feb 1995 23:59:26 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reX8L-0005fUC; Tue, 14 Feb 95 15:58 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA07152
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 15:58:50 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reWZu-000C0KC; Tue, 14 Feb 95 23:22 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reUra-0002g8Z; Tue, 14 Feb 95 21:32 GMT
Message-Id: <m0reUra-0002g8Z.ijackson@nyx.cs.du.edu>
Date: Tue, 14 Feb 95 21:32 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-bugs@pixar.com
Bill Mitchell writes ("Bug#421: unreasonable restriction on term"):
> [...]
> Sounds like a judgement call to me. After checking the Guidelines, I
> think I'd lean towards using the RECOMMEND field instead of DEPENDS
> if it were my judgement call. However, I might lean back in light
> of the new dpkg's capability (going from memory here, since I don't
> have it available just now) to force installation despite not being
> able to satisfy DEPENDS field requirements. That's an expert-user
> sort of option, but we're also talking an expert-user sort of
> situation in wanting to install the term package without a comm
> programm which has been blessed by the term package maintainer.
I had a bad feeling when I put in that option that people might use it
for this kind of thing.
The ONLY REASON people should have to use the --force-<thing> options
in dpkg is to work around some kind of brokenness - either in dpkg
itself or in a package.
Therefore, by definition, requiring the user to say --force-depends
when doing something perfectly reasonable is broken.
Just because these options and facilities exist doesn't mean we should
arrange to make use of them.
Furthermore, the future effects of using --force-depends are rather
unpredictable. In some cases it will be necessary to say
--force-depends on removals of other not-very-related packages, for
example.
>From the Guidelines quote (which I wrote, btw):
+ The DEPENDS field lists packages that are required for this package to
+ provide a significant amount of functionality. The package
+ maintenance software will not allow a package to be installed without
+ also installing packages listed in its DEPENDS field, and will run the
+ postinst scripts of packages listed in DEPENDS fields before those of
+ the packages which depend on them, and run the prerm scripts before.
It is clear that term can provide a significant amount of
functionality without any of the packages that are currently listed in
its DEPENDS field. Package maintainers should read `will not allow'
literally, and not rely on features like --force-*.
+ The RECOMMENDED field lists packages that would be found together with
+ this one in all but unusual installations. The package maintenance
+ software will warn the user if they install a package without those
+ listed in its RECOMMENDED field.
This is the appropriate level of dependency. It is the one that (for
example) the X server and X client software should mutually use.
Ian.
Message received at debian-bugs:
From simons-rock.edu!jimr Tue Feb 14 15:23:11 1995
Return-Path: <jimr@simons-rock.edu>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reWaM-0005kyC; Tue, 14 Feb 95 15:23 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA06018
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 15:23:43 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0reWZu-00001TC; Tue, 14 Feb 95 18:22 EST
Message-Id: <m0reWZu-00001TC@plato.simons-rock.edu>
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: Message from Raul Miller <rdr@merit.edu>
of "Tue, 14 Feb 1995 17:11:36 EST." <199502142211.RAA10789@home.merit.edu>
Date: Tue, 14 Feb 1995 18:22:42 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
[Note: I don't want this to come off as a flame, because these are serious
concerns I have.]
> Sure, and it takes about five minutes to write a primitive (no
> scripting language) terminal emulator for Linux. So, it should be
> trivial to come up with one tailored to the requirements of term,
> which could be supplied with term. Would that be adequate?
But your program is going to have to handle allowing the user to login
to their host system (7bit or 8bit line), allow them enough of an
interface to upload a copy of term source, or term setup files, and
work on them. Your also going to have to make sure it can easily deal
with multiple phone numbers (for people with accounts on different
machines), modem problems (BUSY signals, etc.), and probably some
things I am forgetting. This is all going to have to be bundled into
a package that is easy to setup and use. This seems like a job for a
comm program that is standard (documented, and well supported) and
debian-packaged for easy installation and setup.
I didn't like the idea of changing it to RECOMMENDED, because I am
sure some people who *don't* know what they are doing will sluff it
off, and then complain that Debian Term [favorite expletive(s)]
because they can't set it up on their remote end. This is a pretty
dim view of the end user, but I happen to believe that the lowest
common denominator is what we need to accommodate.
If you are willing to make a comm program that is tailored to term,
and does what I list above, I will be more then willing to bundle it
with term. (In fact, it would be something to send to the current term
author/maintainer, call it tdial or soemthing...)
Jim
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: "James A. Robinson" <jimr@simons-rock.edu>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0reWZu-00001TC@plato.simons-rock.edu>
References: <m0reWZu-00001TC@plato.simons-rock.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: "James A. Robinson" <jimr@simons-rock.edu>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: "James A. Robinson" <jimr@simons-rock.edu>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 23:33:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.021423242025489@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 23:33:01 GMT
Received: with rfc822 via encapsulated-mail id 021423242025489;
Tue, 14 Feb 1995 23:24:20 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reWaM-0005kyC; Tue, 14 Feb 95 15:23 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA06018
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Tue, 14 Feb 1995 15:23:43 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0reWZu-00001TC; Tue, 14 Feb 95 18:22 EST
Message-Id: <m0reWZu-00001TC@plato.simons-rock.edu>
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
In-Reply-To: Message from Raul Miller <rdr@merit.edu>
of "Tue, 14 Feb 1995 17:11:36 EST." <199502142211.RAA10789@home.merit.edu>
Date: Tue, 14 Feb 1995 18:22:42 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
[Note: I don't want this to come off as a flame, because these are serious
concerns I have.]
> Sure, and it takes about five minutes to write a primitive (no
> scripting language) terminal emulator for Linux. So, it should be
> trivial to come up with one tailored to the requirements of term,
> which could be supplied with term. Would that be adequate?
But your program is going to have to handle allowing the user to login
to their host system (7bit or 8bit line), allow them enough of an
interface to upload a copy of term source, or term setup files, and
work on them. Your also going to have to make sure it can easily deal
with multiple phone numbers (for people with accounts on different
machines), modem problems (BUSY signals, etc.), and probably some
things I am forgetting. This is all going to have to be bundled into
a package that is easy to setup and use. This seems like a job for a
comm program that is standard (documented, and well supported) and
debian-packaged for easy installation and setup.
I didn't like the idea of changing it to RECOMMENDED, because I am
sure some people who *don't* know what they are doing will sluff it
off, and then complain that Debian Term [favorite expletive(s)]
because they can't set it up on their remote end. This is a pretty
dim view of the end user, but I happen to believe that the lowest
common denominator is what we need to accommodate.
If you are willing to make a comm program that is tailored to term,
and does what I list above, I will be more then willing to bundle it
with term. (In fact, it would be something to send to the current term
author/maintainer, call it tdial or soemthing...)
Jim
Message received at debian-bugs:
From legislate.com!rdr Tue Feb 14 14:11:35 1995
Return-Path: <rdr@legislate.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reVT4-00062fC; Tue, 14 Feb 95 14:11 PST
Received: from home.merit.edu by pixar.com with SMTP id AA02881
(5.65c/IDA-1.4.4 for <debian-bugs@Pixar.com>); Tue, 14 Feb 1995 14:12:11 -0800
Received: (from rdr@localhost) by home.merit.edu (8.6.9/merit-2.0) id RAA10789; Tue, 14 Feb 1995 17:11:36 -0500
Date: Tue, 14 Feb 1995 17:11:36 -0500
From: Raul Miller <rdr@merit.edu>
Message-Id: <199502142211.RAA10789@home.merit.edu>
To: debian-bugs@Pixar.com
In-Reply-To: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c> (message from Bill Mitchell on Mon, 13 Feb 1995 19:54:40 -0800 (PST))
Subject: Re: Bug#421: unreasonable restriction on term
James A. Robinson:
> I'm sorry but there is no way I want to put term out for
> inexperienced users without also requiring a standard comm
> program. Term is hard enough to setup for new users, and not
> letting them (or forcing those who don't know anthing about term)
> have access decent comm program is, IMO, unreasonable. [...]
Bill Mitchell:
Sounds like a judgement call to me. After checking the Guidelines,
I think I'd lean towards using the RECOMMEND field instead of
DEPENDS if it were my judgement call. However, I might lean back
in light of the new dpkg's capability (going from memory here,
since I don't have it available just now) to force installation
despite not being able to satisfy DEPENDS field requirements.
Well...
perhaps it's time we introduce into debian some sort of concept of a
meta-package, or a package service? In many cases where there's a
list of REQUIRES, it's because there's some sort of generic service
being provided. In the case of term, it's a communications package.
The problem here is that kermit | seyon | minicom is a rather
specialized and heavy duty list for a rather trivial requirement.
Jim Robinson:
I use fet to dial my phone for term, but a lot of people will need
to set term up on their host system. I think it is much better to
make sure they have to comm tools necessary to do so.
Sure, and it takes about five minutes to write a primitive (no
scripting language) terminal emulator for Linux. So, it should be
trivial to come up with one tailored to the requirements of term,
which could be supplied with term. Would that be adequate?
Raul D. Miller
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: Raul Miller <rdr@merit.edu>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <199502142211.RAA10789@home.merit.edu>
References: <199502142211.RAA10789@home.merit.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: Raul Miller <rdr@merit.edu>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 22:18:01 GMT
Resent-Message-ID: <debian-bugs-handler.421.021422124322269@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 22:18:01 GMT
Received: with rfc822 via encapsulated-mail id 021422124322269;
Tue, 14 Feb 1995 22:12:44 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reVT4-00062fC; Tue, 14 Feb 95 14:11 PST
Received: from home.merit.edu by pixar.com with SMTP id AA02881
(5.65c/IDA-1.4.4 for <debian-bugs@Pixar.com>); Tue, 14 Feb 1995 14:12:11 -0800
Received: (from rdr@localhost) by home.merit.edu (8.6.9/merit-2.0) id RAA10789; Tue, 14 Feb 1995 17:11:36 -0500
Date: Tue, 14 Feb 1995 17:11:36 -0500
From: Raul Miller <rdr@merit.edu>
Message-Id: <199502142211.RAA10789@home.merit.edu>
To: debian-bugs@Pixar.com
In-Reply-To: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c> (message from Bill Mitchell on Mon, 13 Feb 1995 19:54:40 -0800 (PST))
James A. Robinson:
> I'm sorry but there is no way I want to put term out for
> inexperienced users without also requiring a standard comm
> program. Term is hard enough to setup for new users, and not
> letting them (or forcing those who don't know anthing about term)
> have access decent comm program is, IMO, unreasonable. [...]
Bill Mitchell:
Sounds like a judgement call to me. After checking the Guidelines,
I think I'd lean towards using the RECOMMEND field instead of
DEPENDS if it were my judgement call. However, I might lean back
in light of the new dpkg's capability (going from memory here,
since I don't have it available just now) to force installation
despite not being able to satisfy DEPENDS field requirements.
Well...
perhaps it's time we introduce into debian some sort of concept of a
meta-package, or a package service? In many cases where there's a
list of REQUIRES, it's because there's some sort of generic service
being provided. In the case of term, it's a communications package.
The problem here is that kermit | seyon | minicom is a rather
specialized and heavy duty list for a rather trivial requirement.
Jim Robinson:
I use fet to dial my phone for term, but a lot of people will need
to set term up on their host system. I think it is much better to
make sure they have to comm tools necessary to do so.
Sure, and it takes about five minutes to write a primitive (no
scripting language) terminal emulator for Linux. So, it should be
trivial to come up with one tailored to the requirements of term,
which could be supplied with term. Would that be adequate?
Raul D. Miller
Message received at debian-bugs:
From mdd.comm.mot.com!mitchell Mon Feb 13 19:55:00 1995
Return-Path: <mitchell@mdd.comm.mot.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reELo-0005oSC; Mon, 13 Feb 95 19:54 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA18624
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 19:55:20 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA10071; Mon, 13 Feb 1995 21:54:44 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA27150; Mon, 13 Feb 1995 21:54:43 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA29681; Mon, 13 Feb 95 19:54:42 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA22716; Mon, 13 Feb 95 19:54:41 PST
Date: Mon, 13 Feb 1995 19:54:40 -0800 (PST)
From: Bill Mitchell <mitchell@mdd.comm.mot.com>
X-Sender: mitchell@bb29c
To: debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: <m0reDgi-00000pC@plato.simons-rock.edu>
Message-Id: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 13 Feb 1995, James A. Robinson wrote:
> > [...] this is a completely unreasonable restriction. For example,
> > here's a simple shell script to allow communication with an arbitrary
> > serial port:
>
> I'm sorry but there is no way I want to put term out for inexperienced
> users without also requiring a standard comm program. Term is hard
> enough to setup for new users, and not letting them (or forcing those
> who don't know anthing about term) have access decent comm program is,
> IMO, unreasonable. [...]
I kind of agree with this, having found term to be less than
newuser friendly myself. However, looking over the debian
packaging Guidelines document, I see:
+ The DEPENDS field lists packages that are required for this package to
+ provide a significant amount of functionality. The package
+ maintenance software will not allow a package to be installed without
+ also installing packages listed in its DEPENDS field, and will run the
+ postinst scripts of packages listed in DEPENDS fields before those of
+ the packages which depend on them, and run the prerm scripts before.
+
+ The RECOMMENDED field lists packages that would be found together with
+ this one in all but unusual installations. The package maintenance
+ software will warn the user if they install a package without those
+ listed in its RECOMMENDED field.
Sounds like a judgement call to me. After checking the Guidelines, I
think I'd lean towards using the RECOMMEND field instead of DEPENDS
if it were my judgement call. However, I might lean back in light
of the new dpkg's capability (going from memory here, since I don't
have it available just now) to force installation despite not being
able to satisfy DEPENDS field requirements. That's an expert-user
sort of option, but we're also talking an expert-user sort of
situation in wanting to install the term package without a comm
programm which has been blessed by the term package maintainer.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: Bill Mitchell <mitchell@mdd.comm.mot.com>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c>
References: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: Bill Mitchell <mitchell@mdd.comm.mot.com>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: Bill Mitchell <mitchell@mdd.comm.mot.com>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 04:03:03 GMT
Resent-Message-ID: <debian-bugs-handler.421.021403561425405@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 04:03:03 GMT
Received: with rfc822 via encapsulated-mail id 021403561425405;
Tue, 14 Feb 1995 03:56:14 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reELo-0005oSC; Mon, 13 Feb 95 19:54 PST
Received: from motgate.mot.com by pixar.com with SMTP id AA18624
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 19:55:20 -0800
Received: from pobox.mot.com by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA10071; Mon, 13 Feb 1995 21:54:44 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <debian-bugs@pixar.com>)
id AA27150; Mon, 13 Feb 1995 21:54:43 -0600
Received: from bb29c.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
id AA29681; Mon, 13 Feb 95 19:54:42 PST
Received: by bb29c.mdd.comm.mot.com (4.1/SMI-4.1)
id AA22716; Mon, 13 Feb 95 19:54:41 PST
Date: Mon, 13 Feb 1995 19:54:40 -0800 (PST)
From: Bill Mitchell <mitchell@mdd.comm.mot.com>
X-Sender: mitchell@bb29c
To: debian-bugs@pixar.com
In-Reply-To: <m0reDgi-00000pC@plato.simons-rock.edu>
Message-Id: <Pine.SUN.3.90.950213194442.22696A-100000@bb29c>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 13 Feb 1995, James A. Robinson wrote:
> > [...] this is a completely unreasonable restriction. For example,
> > here's a simple shell script to allow communication with an arbitrary
> > serial port:
>
> I'm sorry but there is no way I want to put term out for inexperienced
> users without also requiring a standard comm program. Term is hard
> enough to setup for new users, and not letting them (or forcing those
> who don't know anthing about term) have access decent comm program is,
> IMO, unreasonable. [...]
I kind of agree with this, having found term to be less than
newuser friendly myself. However, looking over the debian
packaging Guidelines document, I see:
+ The DEPENDS field lists packages that are required for this package to
+ provide a significant amount of functionality. The package
+ maintenance software will not allow a package to be installed without
+ also installing packages listed in its DEPENDS field, and will run the
+ postinst scripts of packages listed in DEPENDS fields before those of
+ the packages which depend on them, and run the prerm scripts before.
+
+ The RECOMMENDED field lists packages that would be found together with
+ this one in all but unusual installations. The package maintenance
+ software will warn the user if they install a package without those
+ listed in its RECOMMENDED field.
Sounds like a judgement call to me. After checking the Guidelines, I
think I'd lean towards using the RECOMMEND field instead of DEPENDS
if it were my judgement call. However, I might lean back in light
of the new dpkg's capability (going from memory here, since I don't
have it available just now) to force installation despite not being
able to satisfy DEPENDS field requirements. That's an expert-user
sort of option, but we're also talking an expert-user sort of
situation in wanting to install the term package without a comm
programm which has been blessed by the term package maintainer.
Message received at debian-bugs:
From simons-rock.edu!jimr Mon Feb 13 19:12:56 1995
Return-Path: <jimr@simons-rock.edu>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reDh9-0005kyC; Mon, 13 Feb 95 19:12 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA16078
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 19:13:30 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0reDgi-00000pC; Mon, 13 Feb 95 22:12 EST
Message-Id: <m0reDgi-00000pC@plato.simons-rock.edu>
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
In-Reply-To: Message from Raul Miller <rdr@merit.edu>
of "Mon, 13 Feb 1995 18:47:53 EST." <199502132347.SAA27737@home.merit.edu>
Date: Mon, 13 Feb 1995 22:12:28 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
> term won't install unless minicom, kermit, or seyon is installed.
> Presumably, because you need something to dial the phone? [Maybe we
> should have a cu package?]
>
> Anyways, this is a completely unreasonable restriction. For example,
> here's a simple shell script to allow communication with an arbitrary
> serial port:
I'm sorry but there is no way I want to put term out for inexperienced
users without also requiring a standard comm program. Term is hard
enough to setup for new users, and not letting them (or forcing those
who don't know anthing about term) have access decent comm program is,
IMO, unreasonable.
I use fet to dial my phone for term, but a lot of people will need to
set term up on their host system. I think it is much better to make
sure they have to comm tools necessary to do so.
Jim
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: "James A. Robinson" <jimr@simons-rock.edu>
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0reDgi-00000pC@plato.simons-rock.edu>
References: <m0reDgi-00000pC@plato.simons-rock.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: "James A. Robinson" <jimr@simons-rock.edu>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: "James A. Robinson" <jimr@simons-rock.edu>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 03:18:03 GMT
Resent-Message-ID: <debian-bugs-handler.421.021403140423892@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 03:18:03 GMT
Received: with rfc822 via encapsulated-mail id 021403140423892;
Tue, 14 Feb 1995 03:14:04 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reDh9-0005kyC; Mon, 13 Feb 95 19:12 PST
Received: from plato.simons-rock.edu by pixar.com with SMTP id AA16078
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 19:13:30 -0800
Received: from simons-rock.edu by plato.simons-rock.edu with smtp
(Smail3.1.29.1 #1) id m0reDgi-00000pC; Mon, 13 Feb 95 22:12 EST
Message-Id: <m0reDgi-00000pC@plato.simons-rock.edu>
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
In-Reply-To: Message from Raul Miller <rdr@merit.edu>
of "Mon, 13 Feb 1995 18:47:53 EST." <199502132347.SAA27737@home.merit.edu>
Date: Mon, 13 Feb 1995 22:12:28 -0500
From: "James A. Robinson" <jimr@simons-rock.edu>
> term won't install unless minicom, kermit, or seyon is installed.
> Presumably, because you need something to dial the phone? [Maybe we
> should have a cu package?]
>
> Anyways, this is a completely unreasonable restriction. For example,
> here's a simple shell script to allow communication with an arbitrary
> serial port:
I'm sorry but there is no way I want to put term out for inexperienced
users without also requiring a standard comm program. Term is hard
enough to setup for new users, and not letting them (or forcing those
who don't know anthing about term) have access decent comm program is,
IMO, unreasonable.
I use fet to dial my phone for term, but a lot of people will need to
set term up on their host system. I think it is much better to make
sure they have to comm tools necessary to do so.
Jim
Message received at debian-bugs:
From cus.cam.ac.uk!iwj10 Mon Feb 13 18:57:19 1995
Return-Path: <iwj10@cus.cam.ac.uk>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reDS3-0005hOA; Mon, 13 Feb 95 18:57 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA15256
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 18:57:49 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reDQt-000BzaA; Tue, 14 Feb 95 02:56 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reD8r-0002g8A; Tue, 14 Feb 95 02:37 GMT
Message-Id: <m0reD8r-0002g8A.ijackson@nyx.cs.du.edu>
Date: Tue, 14 Feb 95 02:37 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Subject: Re: Bug#421: unreasonable restriction on term
Precedence: air-mail
Raul Miller writes ("Bug#421: unreasonable restriction on term"):
> term won't install unless minicom, kermit, or seyon is installed.
> Presumably, because you need something to dial the phone? [Maybe we
> should have a cu package?]
>
> Anyways, this is a completely unreasonable restriction. For example,
> here's a simple shell script to allow communication with an arbitrary
> serial port: [ deleted - iwj ]
Indeed, this seems an unreasonable restriction.
term should probably use RECOMMENDED rather than DEPENDS here.
Ian.
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Bug#421: Info received (was Bug#421: unreasonable restriction on term)
In-Reply-To: <m0reD8r-0002g8A.ijackson@nyx.cs.du.edu>
References: <m0reD8r-0002g8A.ijackson@nyx.cs.du.edu>
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developers to
accompany the original report.
If you wish to continue submit further information on your problem,
please do the same thing again: send it to debian-bugs@pixar.com, ensuring
that the Subject line starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: iwj10@cus.cam.ac.uk (Ian Jackson), debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: iwj10@cus.cam.ac.uk (Ian Jackson)
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 03:03:11 GMT
Resent-Message-ID: <debian-bugs-handler.421.021402593723340@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 03:03:11 GMT
Received: with rfc822 via encapsulated-mail id 021402593723340;
Tue, 14 Feb 1995 02:59:37 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reDS3-0005hOA; Mon, 13 Feb 95 18:57 PST
Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA15256
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 18:57:49 -0800
Received: by bootes.cus.cam.ac.uk
(Smail-3.1.29.0 #26) id m0reDQt-000BzaA; Tue, 14 Feb 95 02:56 GMT
Received: by chiark (Smail3.1.28.1 #3)
id m0reD8r-0002g8A; Tue, 14 Feb 95 02:37 GMT
Message-Id: <m0reD8r-0002g8A.ijackson@nyx.cs.du.edu>
Date: Tue, 14 Feb 95 02:37 GMT
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Precedence: air-mail
Raul Miller writes ("Bug#421: unreasonable restriction on term"):
> term won't install unless minicom, kermit, or seyon is installed.
> Presumably, because you need something to dial the phone? [Maybe we
> should have a cu package?]
>
> Anyways, this is a completely unreasonable restriction. For example,
> here's a simple shell script to allow communication with an arbitrary
> serial port: [ deleted - iwj ]
Indeed, this seems an unreasonable restriction.
term should probably use RECOMMENDED rather than DEPENDS here.
Ian.
Message received at debian-bugs:
From legislate.com!rdr Mon Feb 13 15:47:58 1995
Return-Path: <rdr@legislate.com>
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reAUn-0006APC; Mon, 13 Feb 95 15:47 PST
Received: from home.merit.edu by pixar.com with SMTP id AA02253
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 15:48:30 -0800
Received: (from rdr@localhost) by home.merit.edu (8.6.9/merit-2.0) id SAA27737; Mon, 13 Feb 1995 18:47:53 -0500
Date: Mon, 13 Feb 1995 18:47:53 -0500
From: Raul Miller <rdr@merit.edu>
Message-Id: <199502132347.SAA27737@home.merit.edu>
To: debian-bugs@pixar.com
Subject: unreasonable restriction on term
term won't install unless minicom, kermit, or seyon is installed.
Presumably, because you need something to dial the phone? [Maybe we
should have a cu package?]
Anyways, this is a completely unreasonable restriction. For example,
here's a simple shell script to allow communication with an arbitrary
serial port:
#!/bin/sh
if tty -s
then
restore='stty '`stty -g`
stty raw -echo
fi
cat <$1 &
id=$!
trap "kill -HUP $id; $restore; exit 1" 1 2 3 5 10 13 15
cat >$1
kill -HUP $id
$restore
exit 0
......................................................................
For term, you might want to do something more like:
#!/bin/sh
(
dialscript
while [ -f /some/file/name ]
do sleep 60
done
) > $1 &
id=$!
sleep 30
term
kill -HUP $!
......................................................................
but the principle is the same: you can talk out the serial port
without any fancy communications packages. [By the way, if term
daemonizes itself, remove that kill line.]
Btw, here might be what dialscript looks like
#!/bin/sh
sleep 2
echo +++
sleep 2
echo ath
sleep 1
echo adtd5551212
sleep 30
echo me
sleep 1
echo secret
sleep 1
echo vt100
......................................................................
Um... cu would be better because you wouldn't have to wait so
unreasonably...
A good perl hacker could probably come up with something better,
too...
Raul D. Miller
Message sent:
From: iwj@cam-orl.co.uk (Ian Jackson)
To: Raul Miller <rdr@merit.edu>
Subject: Bug#421: Acknowledgement (was: unreasonable restriction on term)
In-Reply-To: <199502132347.SAA27737@home.merit.edu>
References: <199502132347.SAA27737@home.merit.edu>
Thank you for the problem report you have sent regarding Debian GNU/Linux.
This is an automatically generated reply, to let you know your message has
been received. It is being forwarded to the developers' mailing list for
their attention; they will reply in due course.
If you wish to submit further information on your problem, please send
it to debian-bugs@pixar.com, but please ensure that the Subject
line of your message starts with "Bug#421" or "Re: Bug#421" so that
we can identify it as relating to the same problem.
Please do not to reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.
Your message didn't have a Package: line at the start (in the
pseudo-header following the real mail header), or didn't have a
psuedo-header at all.
This makes it much harder for us to categorise and deal with your
problem report; please ensure that you say which package(s) and
version(s) the problem is with next time. Some time in the future the
problem reports system may start rejecting such messages.
Ian Jackson
(maintainer, debian-bugs)
Message sent to debian-devel@pixar.com:
Subject: Bug#421: unreasonable restriction on term
Reply-To: Raul Miller <rdr@merit.edu>, debian-bugs@pixar.com
Resent-To: debian-devel@pixar.com
Resent-From: Raul Miller <rdr@merit.edu>
Resent-Sender: iwj10@cus.cam.ac.uk
Resent-Date: Tue, 14 Feb 1995 00:03:02 GMT
Resent-Message-ID: <debian-bugs-handler.421.021323491412906@pixar.com>
X-Debian-PR-Package:
X-Debian-PR-Keywords:
Received: via spool for debian-bugs; Tue, 14 Feb 1995 00:03:02 GMT
Received: with rfc822 via encapsulated-mail id 021323491412906;
Mon, 13 Feb 1995 23:49:14 GMT
Received: from pixar.com by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0reAUn-0006APC; Mon, 13 Feb 95 15:47 PST
Received: from home.merit.edu by pixar.com with SMTP id AA02253
(5.65c/IDA-1.4.4 for <debian-bugs@pixar.com>); Mon, 13 Feb 1995 15:48:30 -0800
Received: (from rdr@localhost) by home.merit.edu (8.6.9/merit-2.0) id SAA27737; Mon, 13 Feb 1995 18:47:53 -0500
Date: Mon, 13 Feb 1995 18:47:53 -0500
From: Raul Miller <rdr@merit.edu>
Message-Id: <199502132347.SAA27737@home.merit.edu>
To: debian-bugs@pixar.com
term won't install unless minicom, kermit, or seyon is installed.
Presumably, because you need something to dial the phone? [Maybe we
should have a cu package?]
Anyways, this is a completely unreasonable restriction. For example,
here's a simple shell script to allow communication with an arbitrary
serial port:
#!/bin/sh
if tty -s
then
restore='stty '`stty -g`
stty raw -echo
fi
cat <$1 &
id=$!
trap "kill -HUP $id; $restore; exit 1" 1 2 3 5 10 13 15
cat >$1
kill -HUP $id
$restore
exit 0
......................................................................
For term, you might want to do something more like:
#!/bin/sh
(
dialscript
while [ -f /some/file/name ]
do sleep 60
done
) > $1 &
id=$!
sleep 30
term
kill -HUP $!
......................................................................
but the principle is the same: you can talk out the serial port
without any fancy communications packages. [By the way, if term
daemonizes itself, remove that kill line.]
Btw, here might be what dialscript looks like
#!/bin/sh
sleep 2
echo +++
sleep 2
echo ath
sleep 1
echo adtd5551212
sleep 30
echo me
sleep 1
echo secret
sleep 1
echo vt100
......................................................................
Um... cu would be better because you wouldn't have to wait so
unreasonably...
A good perl hacker could probably come up with something better,
too...
Raul D. Miller
Ian Jackson /
iwj10@thor.cam.ac.uk,
with the debian-bugs tracking mechanism