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 au
On Tue, May 23, 2000 at 03:14:55PM -0400, Peter S Galbraith 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:
> >
> > debian-doc
> > debian-packagi
> > d
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,
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 wan
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 t
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 evaluati
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 upda
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
> > > - must make sure that errors are trapped. For
> > > + should make sure that errors are trapped.
> > and then (analogous to update-alternatives), it uncomments one of
> > remaining daemons (if any) providing this service
>
> Hrm. Using its own database like update-alternatives, or comments in
> /etc/inetd.conf, or...? Is update-alternatives really the example to
> follow here? I suppose it ma
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
> The same should probably be done for every package which installs daemons
> which listen on a well known port.
Why don't we talk about solving the problem of not having a
mechanism to manage network services instead of trying to make
the Conflicts situation worse?
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 @@
> >
> > Every time you put more than one shell command (this
> > includes using a loop) in a makefile command you
> > -
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 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 Provid
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 di
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 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, debian-m
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 s
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
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
appropr
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 for-
21 matches
Mail list logo
