On Tue, Jul 30, 2002 at 04:51:55AM +0300, Richard Braakman wrote:
> On Mon, Jul 29, 2002 at 05:49:33PM -0700, Chris Waters wrote:
> > After a first skim-through the list, I find myself a little perplexed
> > -- "editor" is not an official, policy-blessed virtual package name,
> > but "lambdamoo-cor
On Mon, Jul 29, 2002 at 05:49:33PM -0700, Chris Waters wrote:
> After a first skim-through the list, I find myself a little perplexed
> -- "editor" is not an official, policy-blessed virtual package name,
> but "lambdamoo-core" is. I think it's safe to say that something's
> wrong with this pictur
On Mon, Jul 29, 2002 at 10:26:52PM +0200, Wichert Akkerman wrote:
> Ok. I think we are actually all in agreement now, Can someone please
> volunteer to go through the list of virtual packages and document
> them properly? For each virtual package we should document
After a first skim-through the
On Mon, Jul 29, 2002 at 10:26:52PM +0200, Wichert Akkerman wrote:
> Ok. I think we are actually all in agreement now, Can someone please
> volunteer to go through the list of virtual packages and document
> them properly? For each virtual package we should document
>
> * a description of what it
Previously Chris Waters wrote:
> If the merely-functional virtual packages were actually useless (which
> is essentially what you said), then I think we would be justified in
> throwing them out. But I don't think they are, so I don't think we
> are.
Ok. I think we are actually all in agreement n
Whoops, I intended that last reply to go to the list. Just shows that
you should check your headers even when you're writing a quick
note. :)
On Mon, Jul 29, 2002 at 01:59:19PM +0200, Wichert Akkerman wrote:
> Previously Chris Waters wrote:
> > Yes, and those virtual packages with no associated i
On Mon, 29 Jul 2002, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> > mail-reader: honestly, I fail to see a reason why this is sane.
> > "less /var/mail/moshez" is as good a mail reader as any.
> > what on earth would prompt someone to suggest a mail-reader
> >
On Mon, Jul 29, 2002 at 02:30:15PM +0200, Wichert Akkerman wrote:
> The same holds for editor which does have a well defined interface.
Well, quite. It's just that you need to put a bit more work into these
things than was being suggested.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Previously Mark Brown wrote:
> You also need to know which command to invoke and you need to know when
> it's safe to discard any temporary file you might be pointing at.
The same holds for editor which does have a well defined interface.
Wichert.
--
__
On Mon, Jul 29, 2002 at 11:57:29AM -, Moshe Zadka wrote:
> www-browser: definitely, here a standard interface (give a URL on the command
> line) is useful. currently, urlview depends on an ugly hack
> to do that (listing browsers itself)
You also need to know which c
Previously Moshe Zadka wrote:
> www-browser: definitely, here a standard interface (give a URL on the command
> line) is useful. currently, urlview depends on an ugly hack
> to do that (listing browsers itself)
doc-central does the same thing.
> mail-reader: honestly, I
On Mon, 29 Jul 2002, Chris Waters <[EMAIL PROTECTED]> wrote:
> If that were true, then nothing would depend on mail-reader or
> www-browser or audio-mixer. But things do.
I'm not a big audio person, so I can't comment on audio-mixer.
www-browser: definitely, here a standard interface (give a UR
Previously Chris Waters wrote:
> Some virtual packages (mail-transport-agent, c-compiler, httpd, most
> of *-server) clearly do have an associated interface. Some
> (mail-reader, www-browser, audio-mixer) clearly do not.
Lack of an interface tends to be troublesome. Look at doc-central
for exampl
On Mon, Jul 29, 2002 at 11:17:57AM +0200, Wichert Akkerman wrote:
> A virtual package is a means to indicate a package provides a certain
> interface, not some functionality.
Some virtual packages (mail-transport-agent, c-compiler, httpd, most
of *-server) clearly do have an associated interface.
Previously Moshe Zadka wrote:
> Ummm.if a C compiler doesn't support a /usr/bin/cc which supports -o
> and -c, it shouldn't "Provide: c-compiler"
A virtual package is a means to indicate a package provides a certain
interface, not some functionality. Functionality is useless if you
can't use i
On Sun, 28 Jul 2002, Branden Robinson <[EMAIL PROTECTED]> wrote:
> > I wouldn't say so. For example, a C compiler ought to provide
> > /usr/bin/cc in some form or another,
>
> You're talking about an alternative for /usr/bin/cc. A thing that
> compiles C source code into object files is a C com
On Sun, Jul 28, 2002 at 12:57:19PM -0500, Branden Robinson wrote:
> On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote:
> > a mail transport agent ought to provide a /usr/sbin/sendmail
> > implementation
> Only if policy says so. In and of itself this isn't a requirement
> mandated by th
On Sun, Jul 28, 2002 at 01:00:55PM -0500, Branden Robinson wrote:
> On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote:
> > all other) case. Perhaps something like "DHCP clients compatible with
> > ifup/ifdown"
> dead in the water. I doubt that providing a description as you suggest
>
On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote:
> Branden> These appear to be equally valid arguments against all
> Branden> other virtual packages in Debian.
>
> To mee this is simply an argument that the description entry in the
> virtual packages list should be carefully wr
On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote:
> I wouldn't say so. For example, a C compiler ought to provide
> /usr/bin/cc in some form or another,
You're talking about an alternative for /usr/bin/cc. A thing that
compiles C source code into object files is a C compiler regardless
On Sat, Jul 27, 2002 at 09:28:56PM -0500, Branden Robinson wrote:
> On Sat, Jul 27, 2002 at 09:20:03PM +0100, Mark Brown wrote:
> > It seems pointless given that you can't actually depend on the package
> > and expect it to do anything in particular - the package seems to serve
> > no purpose. I
> "Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:
Branden> On Sat, Jul 27, 2002 at 09:20:03PM +0100, Mark Brown
Branden> wrote:
>> It seems pointless given that you can't actually depend on the
>> package and expect it to do anything in particular - the
>> package
On Sat, Jul 27, 2002 at 09:20:03PM +0100, Mark Brown wrote:
> It seems pointless given that you can't actually depend on the package
> and expect it to do anything in particular - the package seems to serve
> no purpose. I mean, as far as I can tell a package providing access to
> raw sockets woul
On Fri, Jul 26, 2002 at 11:03:05AM -0500, Branden Robinson wrote:
> Do you formally object to the proposed update to the virtual packages
> list?
It seems pointless given that you can't actually depend on the package
and expect it to do anything in particular - the package seems to serve
no purpo
On Thu, Jul 25, 2002 at 05:09:06PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2002 at 10:21:15AM -0500, Branden Robinson wrote:
>
> > Etherconf never invokes anything other than ifup and ifdown. It's ifup
> > that has the smarts. I know it already handles dhcp-client and pump;
> > i think (but m
On Thu, Jul 25, 2002 at 10:21:15AM -0500, Branden Robinson wrote:
> Etherconf never invokes anything other than ifup and ifdown. It's ifup
> that has the smarts. I know it already handles dhcp-client and pump;
> i think (but may be wrong) that Branden has seen it work with udhcpc.
So what you'r
- Forwarded message from Eric Gillespie <[EMAIL PROTECTED]> -
From: Eric Gillespie <[EMAIL PROTECTED]>
To: Matt Kraai <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Bug#154142: dhcp-client conflicts
Date: Thu, 25 Jul 2002 10:05:09 -0500
Message-Id: <[EMAIL PROTECTED]>
User-Agent: nmh/1.0
27 matches
Mail list logo
