It seems pointless, in my opinion, to put information common to all
packages into the man page of each. This is like requiring all car
license tags to say car on them. Well, we already KNOW that much.
(As an aside, ISBNs do not come from the Library of Congress, but actually
come from the
If seems to me that what is wanted here is a superfinger daemon, a sort
of mini-inetd. It would accept the connection from inetd, make a decision
based upon some set of system or per-user configuration files as to which
finger daemon should be spawned, and then hand the connection to the
On Tue, May 23, 2000 at 02:35:40AM -0400, Mike Bilow wrote:
If seems to me that what is wanted here is a superfinger daemon, a sort
of mini-inetd.
More likely, we need a new update-inetd that actually handles these sorts
of situations elegantly. This probably isn't that hard a job, but it's not
On Mon, May 22, 2000 at 02:30:04PM +0100, Julian Gilbey wrote:
| Is there any naming convention for debian-specific documentation
| packages? I would have expected such things to be called debian-blah,
| similar to debian-policy.
What do folks think?
I've long wanted to see that!
On Tue, May 23, 2000 at 01:28:05PM +0200, Josip Rodin wrote:
I've long wanted to see that! The primary packages I'd like to see
change their names are:
packaging-manual, developers-reference, maint-guide, doc-debian
To debian-packaging-manual, debian-developers-reference,
On Mon, May 22, 2000 at 10:05:30PM +0200, [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.1.1.1
The line Debian uses the serial device /dev/tty should read
Debian uses the serial device /dev/ttyS.
Yup, it should. Will fix.
Julian
--
On Sun, May 21, 2000 at 07:01:57PM +1000, Anthony Towns wrote:
Since there don't seem to be any objections to the principle of this,
I'd like to formally propose that we clarify the significance of the
various policy guidelines with more precise musts and shoulds.
This I second... but the diff
On Mon, May 22, 2000 at 12:23:00PM -0400, Ben Collins wrote:
Just a thought on the fingerd thread. What about having a general policy
for network services in that perform a function. Basically it would say
something like:
A package which provides a network service can opt to Provide
On Tue, 23 May 2000, Julian Gilbey wrote:
Is there a really good reason why we shouldn't have long package names?
dpkg -l, but this is not a really good reason :-)
On Tue, May 23, 2000 at 04:13:30PM +0200, Josip Rodin wrote:
This I second... but the diff itself still has a few issues.
@@ -1046,12 +1065,12 @@
p
Every time you put more than one shell command (this
includes using a loop) in a makefile command you
-
On Tue, May 23, 2000 at 05:15:33PM +0200, Radovan Garabik wrote:
For this, there should be some central authority deciding about
/etc/inetd.conf. update-inetd is a good try, but not complete enough
Something more like update-alternatives could work.
update-inetd is just buggy (in design, if
On Wed, May 24, 2000 at 01:07:12AM +1000, Anthony Towns wrote:
Every time you put more than one shell command (this
includes using a loop) in a makefile command you
- emmust/em make sure that errors are trapped. For
+ should make sure that errors are trapped. For
On Wed, May 24, 2000 at 02:03:07AM +1000, Anthony Towns wrote:
On Tue, May 23, 2000 at 05:15:33PM +0200, Radovan Garabik wrote:
For this, there should be some central authority deciding about
/etc/inetd.conf. update-inetd is a good try, but not complete enough
Something more like
On Tue, May 23, 2000 at 05:11:45PM +0200, Santiago Vila wrote:
On Tue, 23 May 2000, Julian Gilbey wrote:
Is there a really good reason why we shouldn't have long package names?
dpkg -l, but this is not a really good reason :-)
I had thought of that one, and I agree with your evaluation of
Julian Gilbey wrote:
On Tue, May 23, 2000 at 05:11:45PM +0200, Santiago Vila wrote:
On Tue, 23 May 2000, Julian Gilbey wrote:
Is there a really good reason why we shouldn't have long package names?
dpkg -l, but this is not a really good reason :-)
I had thought of that one, and
On Tue, May 23, 2000 at 07:14:47PM +0100, Julian Gilbey wrote:
I had thought of that one, and I agree with your evaluation of its
significance. You see, dpkg -l gives 14 columns of package name in an
80-column terminal, so you would see:
dpkg -l is (IMHO) very frustrating. Just when you want
On Wed, May 24, 2000 at 08:12:21AM +1000, Hamish Moffatt wrote:
On Tue, May 23, 2000 at 07:14:47PM +0100, Julian Gilbey wrote:
I had thought of that one, and I agree with your evaluation of its
significance. You see, dpkg -l gives 14 columns of package name in an
80-column terminal, so you
Jules Bean wrote:
Agreed.
On the other hand, I can't believe it's more than a ten minute change
to fix it. And we're not short of C programmers round here...
[EMAIL PROTECTED]:~dpkg -l | grep kernel
ii autofs 3.1.4-4 A
kernel-based
18 matches
Mail list logo
