Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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-core is. I think it's safe to say that something's wrong with this picture. (And it's just the tip of the iceburg, of course.) That's because editors are special :) From policy 12.4: Ok, fair enough, but then substitute c++-compiler or nfs-client or radius-server for editor. All are actual virtual package names in use in the system, and all are probably useful, but none are officially blessed. Unlike lambdamoo-core. :) Anyone who hasn't looked may find the list of actual virtual packages (which can be seen in aptitude) interesting and informative, and possibly a little frightening. The virtual-packages changelog shows that an editor entry was actually added and then removed in 1996. Then I won't plan to propose that we re-add it. :) But I am starting to think that we should stop and examine our list of officially blessed virtual package names, our list of _actual_ virtual package names, and see if there aren't a few that should be added to or removed from the former. And since I've already opened my big fat mouth and volunteered to document the interfaces for the official virtual packages, I'd rather not get stuck with this job too. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 compiler regardless of where its binary lives or what it's called. Ummm.if a C compiler doesn't support a /usr/bin/cc which supports -o and -c, it shouldn't Provide: c-compiler 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 the fact that Provides: mail-transport-agent is in a package's control data. Policy refers to the FHS, and the FHS says sendmail or compatible programs should provide /u/s/sm [and symlink deprecated /u/l/sm to it]. There's no fundamental reason you couldn't have multiple MTAs listening on different ports Being an MTA has nothing to do with listening on port 25, and everything to do with supplying a /u/s/sm pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! You don't need to: you can get that information out of the MIME support it has to include. If a PDF viewer does not supply PDF mime support, it should not provide the virtual package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 it in a standard way. If a random package X can not rely on and use expected behaviour by random package Y that provides a virtual package Z without hardcoding specific on Z we might as well ditch the concept of virtual packages. For MTAs the standard interface is /usr/sbin/sendmail with a couple of standard commandline options (LSB has a nice list). For a C compiler the interface is /usr/bin/cc with a few common options (which definitely include -c and -o). If policy is currently unclear on this we should improve the policy text. It definitely makes sense for each virtual package to specify the exact interface it represents. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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. Some (mail-reader, www-browser, audio-mixer) clearly do not. Functionality is useless if you can't use it in a standard way. If that were true, then nothing would depend on mail-reader or www-browser or audio-mixer. But things do. If policy is currently unclear on this we should improve the policy text. It definitely makes sense for each virtual package to specify the exact interface it represents. For those virtual packages which have an assumed interface (which is probably most of them), I fully agree. Good: Documenting interfaces for virtual packages. Bad: throwing out virtual packages which lack an interface to document. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 example: it has to guess which web browser you have installed. Other programs will have the exact same problem. In this case the interface is really minimal (how does one start a browser), but the lack of a well defined interface is problematic. If that were true, then nothing would depend on mail-reader or www-browser or audio-mixer. But things do. And things could be better if they could actually start a mail-reader automatically :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 URL on the command line) is useful. currently, urlview depends on an ugly hack to do that (listing browsers itself) 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 is truly beyond me. Should a mail-reader also be able to *send* mail? That would actually make it a useful virtual package, again with a minimum of interface (accept an address on the command line, e.g.) For those virtual packages which have an assumed interface (which is probably most of them), I fully agree. Good: Documenting interfaces for virtual packages. Bad: throwing out virtual packages which lack an interface to document. Better: adding interfaces for those virtual packages which lack an interface, and supplying patches to support those interfaces, and throwing those which truly serve no purpose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 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
is truly beyond me.
Mail notification programs what start a MUA when you click on them
for example.
Should a mail-reader also be able to *send* mail? That would actually
make it a useful virtual package, again with a minimum of interface
(accept an address on the command line, e.g.)
The name mail-reader suggests it doesn't. Perhapt it would be useful
to introduce mail-user-agent, which is both a common name, unlike
mail-reader, and has a proper definition:
mail user agent
messaging (MUA) The program that allows the user to compose
and read {electronic mail} messages. The MUA provides the
interface between the user and the {Message Transfer Agent}.
Outgoing mail is eventually handed over to an MTA for delivery
while the incoming messages are picked up from where the MTA
left it (although MUA's running on single-user machines may
pick up mail using {POP}).
Better: adding interfaces for those virtual packages which lack an interface,
and supplying patches to support those interfaces, and throwing
those which truly serve no purpose.
Definitely.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 command to invoke and you need to know when it's safe to discard any temporary file you might be pointing at. 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 is truly beyond me. Should a mail-reader also be able to *send* mail? That would actually make it a useful virtual package, again with a minimum of interface (accept an address on the command line, e.g.) Being able to read mail is enough for some packages (nethack, for example (not that it suggests this)). -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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
is truly beyond me.
Mail notification programs what start a MUA when you click on them
for example.
However, let me tell you what *currently* suggests mail-reader: MTAs.
Why? Damned if I know. As mail reader stands now, it is next to useless.
What you suggest is nice, but would require a different definition of
mail-reader (that is something which reads /var/mail/something).
In this case, pms (which is mine) and nmh (which is someone else's) should
stop Provide:ing m-r.
The name mail-reader suggests it doesn't. Perhapt it would be useful
to introduce mail-user-agent, which is both a common name, unlike
mail-reader, and has a proper definition:
mail user agent
messaging (MUA) The program that allows the user to compose
and read {electronic mail} messages. The MUA provides the
interface between the user and the {Message Transfer Agent}.
Outgoing mail is eventually handed over to an MTA for delivery
while the incoming messages are picked up from where the MTA
left it (although MUA's running on single-user machines may
pick up mail using {POP}).
Yep, I think that'd be useful. Again, I give urlview as an example of
something which would like a common interface. Also, browsers which are
capable of launching external programs for mailto: urls could use that
interface.
So far, all examples I can think of mandate an interface as a well-defined
path to a binary, with either Conflicts: or update-alternatives to negotiate
between multiple potential providers.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 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 should be used for * a complete description of the interface packages should provide if that is relevant for that virtual package Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 should be used for * a complete description of the interface packages should provide if that is relevant for that virtual package I'll take a stab at it. I made need to consult about some of the entries. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 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 picture. (And it's just the tip of the iceburg, of course.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 picture. (And it's just the tip of the iceburg, of course.) That's because editors are special :) From policy 12.4: It is not required for a package to depend on `editor' and `pager', nor is it required for a package to provide such virtual packages.[1] [1] The Debian base system already provides an editor and a pager program, I guess the reasoning is that any system will have at least one editor, even though no editor is Essential. Or maybe it's because it is so easy to have EDITOR point to a non-packaged editor. Note that sensible-editor itself is in debianutils. The virtual-packages changelog shows that an editor entry was actually added and then removed in 1996. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 mean, as far as I can tell a package providing access to These appear to be equally valid arguments against all other virtual packages in Debian. I wouldn't say so. For example, a C compiler ought to provide /usr/bin/cc in some form or another, a mail transport agent ought to provide a /usr/sbin/sendmail implementation and a web server ought to serve things out of /var/www by default. Other virtual packages appear to be more about ensuring that only one package tries to use a given resource at one time. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 of where its binary lives or what it's called. 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 the fact that Provides: mail-transport-agent is in a package's control data. and a web server ought to serve things out of /var/www by default. Purely an FHS issue. A web server is a thing that speaks HTTP over a network interface (which may be virtualized). By the way, the virtual package name for a web server is httpd. Other virtual packages appear to be more about ensuring that only one package tries to use a given resource at one time. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I don't think that is possible in the former case due to /usr/sbin/sendmail, but that's something we decided to do and not an inherent restriction imposed by the MTAs themselves. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. However, I give up. Unless the maintainers of the various and sundry DHCP client packages in Debian decide to cooperate there's no way that #154142 can be solved in a way that makes both the submitter and the maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, when a DCHP client package dies, etherconf will refer to a nonexistent one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. I expect you to be calling for the removal of a great many virtual packages listed in /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, because they define an insufficiently strict interface. pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the pdf-viewer input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that only one pdf-viewer is installed at a time; there are precious resources that are monopolized by such tools. We need to be enhancing the user experience in Debian by doing away with these meaningless virtual packages! -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen pgpByEzsDh7yI.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 written in this (and really all other) case. Perhaps something like DHCP clients compatible with ifup/ifdown This discussion appears to be irrelevant. None of the DHCP client maintainers has said, yes, good idea, I'll do this, therefore it's dead in the water. I doubt that providing a description as you suggest will do anything to overcome Mark Brown's opposition to the idea. -- G. Branden Robinson|A committee is a life form with six Debian GNU/Linux |or more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | pgphR0tHl11Fi.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 will do anything to overcome Mark Brown's opposition to the idea. Your doubts are unfounded - that description works for me. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 the fact that Provides: mail-transport-agent is in a package's control data. Yet irrespective of policy any package not providing /usr/sbin/sendmail and claiming to be a mail-transport-agent is going to break a fair chunk of the packages which declare a dependency on that virtual package since they declare the dependency because they need to use that interface. This is one of the reasons why we specify what a package must do to be considered a mail-transport-agent. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I I agree. I think it would be a good thing if this were well supported by the packages providing servers. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. I've read it before, I've just re-read it and I still don't see why you'd want to be having packages satisfy dpkg dependencies when they don't satisfy the actual dependencies. maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, You still have this problem every time a package implements this virtual package with a new interface. one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. It's more mystical notions about what the dependency information we provide for packages is good for. pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the pdf-viewer input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that If you were to really push for something I'd suggest that the interface a pdf-viewer should provide is that we normally use for handling MIME but that's not really the point and doesn't apply to a lot of the other virtual packages. These are like news-reader where the idea appears to be that a user will use the package for themselves (This package will be pretty useless unless you can view PDFs - I suggest you have a PDF viewer installed). I'm rather ambivalent about the usefulness of this given the difficulty in implementing user interfaces for suggests and recommends but that's another matter. dhcp-client really doesn't seem like it's going to be used like that - the context that sparked its request certainly isn't one where that's the case. It's not about asking for publication ready standards documents for virtual packages. Adding supported by ifupdown as was suggested would do everything that's being asked for if it's how dhcp-client is supposed to be used. Having said all that, given the enthusiasm with which your formal proposal has been greeted I guess I'm just misunderstanding why we have dependencies. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 purpose. I mean, as far as I can tell a package providing access to raw sockets would fulfil the role (It does DHCP if you use the right commands!). Perhaps I just don't understand what this package is intended to achieve? I don't know if I'd go so far as a formal objection, though. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 seems to serve no purpose. I mean, as far as I can tell a package providing access to raw sockets would fulfil the role (It does DHCP if you use the right commands!). Perhaps I just don't understand what this package is intended to achieve? 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 written in this (and really all other) case. Perhaps something like DHCP clients compatible with ifup/ifdown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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 may be wrong) that Branden has seen it work with udhcpc. So what you're saying is that the standard interface should be that provided by ifup and ifdown. No, that's how *etherconf* elects to take advantage of DHCP clients. There's no onus on anything else to work that way. There's nothing particularly wrong with that - it's just that it needs to be know that that's how things work. But it isn't, necessarily. Perhaps some sort of interface description ought to be added to the virtual packages list in policy? I still don't think that is necessary. Do you formally object to the proposed update to the virtual packages list? -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to [EMAIL PROTECTED] | unlearn old falsehoods. http://people.debian.org/~branden/ | -- Robert Heinlein pgpsMONl9ulap.pgp Description: PGP signature
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 08:59:12PM -0500, Branden Robinson wrote: On Wed, Jul 24, 2002 at 12:48:43PM -0700, Matt Kraai wrote: Suppose that no common interface is provided: if etherconf doesn't know how to invoke udhcpc, then having udhcpc provide dhcp-client will break etherconf's DHCP support. That's etherconf's problem and not a reason to object to a dhcp-client virtual package. Then you've not got a very useful virtual package - things wanting to use the virtual package still need to go through and support every DHCP client individually only now they won't be expressing that clearly in their dependancies. If you can't depend on dhcp-client and know that you'll be able to do something constructive with the package that satisfies that dependancy then what's the point? I assume we don't want to use the packages to conflict. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[epg@progeny.com: Bug#154142: dhcp-client conflicts]
- 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.4+dev (i386-unknown-netbsdelf1.5ZA) Matt Kraai [EMAIL PROTECTED] writes: Suppose that no common interface is provided: if etherconf doesn't know how to invoke udhcpc, then having udhcpc provide dhcp-client will break etherconf's DHCP support. 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. -- Eric Gillespie * [EMAIL PROTECTED] Software Developer Progeny Linux Systems - http://progeny.com/ When everyone has to reinvent the wheel, many people invent square wheels. - End forwarded message - -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Thu, Jul 25, 2002 at 10:44:13AM -0500, Branden Robinson wrote: On Thu, Jul 25, 2002 at 08:29:22AM -0700, Matt Kraai wrote: On Thu, Jul 25, 2002 at 10:05:09AM -0500, Eric Gillespie wrote: Matt Kraai [EMAIL PROTECTED] writes: Suppose that no common interface is provided: if etherconf doesn't know how to invoke udhcpc, then having udhcpc provide dhcp-client will break etherconf's DHCP support. 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. In that case I withdraw my objections. Please tell that to debian-policy; better yet, second my request for a dhcp-client virtual package. OK, I second Branden's request. Matt pgpLbF7GVIi3x.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
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're saying is that the standard interface should be that provided by ifup and ifdown. There's nothing particularly wrong with that - it's just that it needs to be know that that's how things work. Perhaps some sort of interface description ought to be added to the virtual packages list in policy? -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 10:20:06AM -0700, Matt Kraai wrote: On Wed, Jul 24, 2002 at 12:53:50PM -0400, Simon Law wrote: What do you guys think? It seems to me that it should be a pretty reasonable thing to push into the next upload. The clients are not interchangable, as they have different interfaces (see #113620). etherconf should depend on an alternative of the clients it supports. Your reasoning is backwards. x-terminal-emulators and mail-tranfer-agents aren't interchangeable either, and have different command line interfaces or configuration file formats. A lot of the time, though, that simply doesn't matter. The correct solution IMO is to have the virtual package and define a baseline set of functionality if necessary. Packages with more specific requirements of a DCHP client can depend only on the clients they support. Packages that require little of, and are truly agnostic about, the DHCP client should not have to enumerate every DHCP client in the distribution in their dependency information. Otherwise everyone who depends on a DHCP client has to rev their package when a new DCHP client is added to the distro. If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
[Please excuse my terseness. I'm learning the Dvorak keyboard and this makes me economize my words even more than usual.] On Wed, Jul 24, 2002 at 12:36:59PM -0500, Branden Robinson wrote: On Wed, Jul 24, 2002 at 10:20:06AM -0700, Matt Kraai wrote: On Wed, Jul 24, 2002 at 12:53:50PM -0400, Simon Law wrote: What do you guys think? It seems to me that it should be a pretty reasonable thing to push into the next upload. The clients are not interchangable, as they have different interfaces (see #113620). etherconf should depend on an alternative of the clients it supports. Your reasoning is backwards. x-terminal-emulators and mail-tranfer-agents aren't interchangeable either, and have different command line interfaces or configuration file formats. A lot of the time, though, that simply doesn't matter. The correct solution IMO is to have the virtual package and define a baseline set of functionality if necessary. Packages with more specific requirements of a DCHP client can depend only on the clients they support. Packages that require little of, and are truly agnostic about, the DHCP client should not have to enumerate every DHCP client in the distribution in their dependency information. Otherwise everyone who depends on a DHCP client has to rev their package when a new DCHP client is added to the distro. If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. This compatibility does not currently exist. udhcpc, for instance, will by default not exit unsuccessfully if it fails to obtain a lease. Other clients use a different option to control this, or do it by default. Similarly for choosing which interface to configure. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. I was citing it as an example of how widely the interfaces differ, not of how the dependencies should be handled. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 11:07:02AM -0700, Matt Kraai wrote: [Please excuse my terseness. I'm learning the Dvorak keyboard and this makes me economize my words even more than usual.] So come back to the QWERTY dark side. Quicker, easier. :) If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. This compatibility does not currently exist. udhcpc, for instance, will by default not exit unsuccessfully if it fails to obtain a lease. Other clients use a different option to control this, or do it by default. Similarly for choosing which interface to configure. It's my contention that for the purposes of a virtual package, this simply doesn't matter. postfix, sendmail, and exim exhibit different behaviors as well; that doesn't make them non-mail-transfer-agents. Perhaps you're thinking of alternatives, where command-line compatibility -- at least to some defined extent -- is required. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. I was citing it as an example of how widely the interfaces differ, not of how the dependencies should be handled. So you have no objection to a dhcp-client virtual package, then? -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 01:09:22PM -0500, Branden Robinson wrote: On Wed, Jul 24, 2002 at 11:07:02AM -0700, Matt Kraai wrote: [Please excuse my terseness. I'm learning the Dvorak keyboard and this makes me economize my words even more than usual.] So come back to the QWERTY dark side. Quicker, easier. :) No kidding. If we handle dhcp-client as we do other virtual packages, the specific knowledge is expressed where it is needed (i.e., my package can use udhcpc and nothing else ), and not everywhere *except* where it's needed. This compatibility does not currently exist. udhcpc, for instance, will by default not exit unsuccessfully if it fails to obtain a lease. Other clients use a different option to control this, or do it by default. Similarly for choosing which interface to configure. It's my contention that for the purposes of a virtual package, this simply doesn't matter. postfix, sendmail, and exim exhibit different behaviors as well; that doesn't make them non-mail-transfer-agents. Perhaps you're thinking of alternatives, where command-line compatibility -- at least to some defined extent -- is required. But they do provide (at least some) command-line compatibility, /usr/lib/sendmail. #113620 has little to do with this. ifupdown declares no dependency on any DHCP client. That it did not properly support udhcpc has nothing to do with package dependencies and thus nothing to do with virtual packages. I was citing it as an example of how widely the interfaces differ, not of how the dependencies should be handled. So you have no objection to a dhcp-client virtual package, then? Suppose `Provides: dhcp-client' is added to udhcpc. Does it also need to provide a script, /sbin/dhcp-client, which invokes udhcpc with the correct options, and conflict with the other DHCP clients? Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 11:26:08AM -0700, Matt Kraai wrote: Suppose `Provides: dhcp-client' is added to udhcpc. Does it also need to provide a script, /sbin/dhcp-client, which invokes udhcpc with the correct options, and conflict with the other DHCP clients? Not necessarily, no. A virtual package tells you what the *package* is. It's the job of alternatives to deal with files in the filesystem. I'm not saying there isn't value in having some generic dhcp-client command-line interface that Debian can define; I'm just saying it's not necessary for the specification of a virtual package, and I don't think etherconf needs it, either. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#154142: dhcp-client conflicts
On Wed, Jul 24, 2002 at 01:45:14PM -0500, Branden Robinson wrote: On Wed, Jul 24, 2002 at 11:26:08AM -0700, Matt Kraai wrote: Suppose `Provides: dhcp-client' is added to udhcpc. Does it also need to provide a script, /sbin/dhcp-client, which invokes udhcpc with the correct options, and conflict with the other DHCP clients? Not necessarily, no. A virtual package tells you what the *package* is. It's the job of alternatives to deal with files in the filesystem. We need a common interface to avoid duplication between etherconf and ifupdown (and to allow new clients to be used without having to change ifupdown). Would the best way to achieve this be for each client to provide an alternative for /sbin/dhcp-client, with some agreed-upon interface and semantics? I'm not saying there isn't value in having some generic dhcp-client command-line interface that Debian can define; I'm just saying it's not necessary for the specification of a virtual package, and I don't think etherconf needs it, either. Suppose that no common interface is provided: if etherconf doesn't know how to invoke udhcpc, then having udhcpc provide dhcp-client will break etherconf's DHCP support. Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
