Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Le jeudi, 11 juillet 2013 02.27:52, Russ Allbery a écrit : Steve Langasek vor...@debian.org writes: If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all (or at least, there's no reason to label it an 'lsb' package). I think the purpose of the package is to let lsb-core be installed without automatically pulling in an MTA that has to be configured, and default-mta | mail-transport-agent | lsb-invalid-mta wouldn't achieve that. But I think dropping the Provides: from lsb-invalid-mta would. Ah, I see. Hm. I do think that the behavior a user most likely expects, when installing lsb-core, is to pull in a functional MTA. In other words, I think it's fine to provide a way for a sysadmin to select to not configure an MTA, but I do think that installing lsb-core should result in configuring an MTA by default. I am of the opposite opinion: if an administrator decided to uninstall the default-mta as installed by Debian, then the installation of lsb- core should respect that choice and not impose the configuration of an MTA, especially because lsb-* is meant as a compliance layer, not a functional layer (in my understanding). As argued before in this bug, LSB only formally requires the presence of a compliant sendmail command, not that this one does anything useful. I think I quite like Steve's line: make lsb-invalid-mta stop providing mail-transport-agent. In all but unusual Debian installations (in which the administrator decided to remove all MTAs), the installation of lsb- core will result in the re-use of the installed MTA. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Le mercredi, 10 juillet 2013 20.20:21, Steve Langasek a écrit : On Wed, Jul 10, 2013 at 02:10:22AM -0700, Russ Allbery wrote: (It's probably also worth noting that Debian does not claim LSB compliance and the description of that Debian package states, rather prominently: The intent of this package is to provide a best current practice way of installing and running LSB packages on Debian GNU/Linux. Its presence does not imply that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant. So, really, it's kind of hard to see what's notably egregious about this.) Well, I think that package description is silly in its lawyeresque weaselness. The raison d'être of the package is to provide an LSB-compliant layer, which is what it means to support installing and running LSB packages. I don't see any reason the package description should have this long disclaimer about the possibility of bugs in the implementation. The core of what this phrasing [0] conveys is this package doesn't imply that Debian is LSB-compliant but is our best-effort at it; I would welcome any patch in that direction, if possible acked by Jeff/LSB. Cheers, OdyX [0] Which apparently has been that was at least since 2002 for the LSB 1.1.0-11 package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
On Wed, 2013-07-10 at 17:25 -0700, Steve Langasek wrote: If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all I agree. None of the suggested solutions address the crontab issue, and there may be other similar problems we haven't found yet. I realise that Ubuntu perceives this as a problem, and it seems to stem from the fact that Debian's default sendmail client implementation (exim4) is intimately tied to the server component. But Debian != Ubuntu, and I agree with Debian's definition that an MTA should consist of both server and client components. That said, there is no reason why a simple sendmail client cannot be provided separately by those distributions which don't want to have to install a server - is this a completely unreasonable course of action for Canonical to take? IMHO, as far as Debian is concerned, lsb-invalid-mta has to go. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
On Thu, Jul 11, 2013 at 09:53:52AM +0200, Aaron Sowry wrote: On Wed, 2013-07-10 at 17:25 -0700, Steve Langasek wrote: If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all I agree. None of the suggested solutions address the crontab issue, and there may be other similar problems we haven't found yet. No, you aren't agreeing. I'm saying that *either* lsb-core should prefer lsb-invalid-mta, *or* lsb-invalid-mta should not exist. lsb-invalid-mta, without a Provides: mail-transport-agent, *does* satisfy the cron issue. I realise that Ubuntu perceives this as a problem, and it seems to stem from the fact that Debian's default sendmail client implementation (exim4) is intimately tied to the server component. But Debian != Ubuntu, and I agree with Debian's definition that an MTA should consist of both server and client components. Debian has no definition of an MTA that says anything about server and client components. Also, lsb-invalid-mta may have originated in Ubuntu, but that doesn't mean Ubuntu has different requirements from Debian here. The lsb-invalid-mta package as implemented is buggy with respect to *both* distributions, for the reason I described. That said, there is no reason why a simple sendmail client cannot be provided separately by those distributions which don't want to have to install a server - is this a completely unreasonable course of action for Canonical to take? For the record, this is not a decision for Canonical to take, it is a decision to be made by the Ubuntu community. And no, this would not solve the problem that lsb-invalid-mta was introduced to solve, which is that *you can't have a working mta without prompting the user for configuration*. There are plenty of implementations of mail-transport-agent in Debian and Ubuntu which don't require running a daemon (nullmailer, ssmtp), but if you expect to use them to send mail, you still need them to be configured, and that's what this package is intended to avoid. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
On Thu, 2013-07-11 at 08:33 -0700, Steve Langasek wrote: No, you aren't agreeing. I'm saying that *either* lsb-core should prefer lsb-invalid-mta, *or* lsb-invalid-mta should not exist. lsb-invalid-mta, without a Provides: mail-transport-agent, *does* satisfy the cron issue. Okay, I misunderstood. And no, this would not solve the problem that lsb-invalid-mta was introduced to solve, which is that *you can't have a working mta without prompting the user for configuration*. There are plenty of implementations of mail-transport-agent in Debian and Ubuntu which don't require running a daemon (nullmailer, ssmtp), but if you expect to use them to send mail, you still need them to be configured, and that's what this package is intended to avoid. P1) You can't have a working MTA without prompting the user for configuration. P2) Prompting the user for configuration is bad. P3) A non-working MTA is bad. C) Therefore, the solution is to install a non-working MTA. I... what? I'm not sure I have anything more to contribute to this discussion. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
On Wed, Jul 10, 2013 at 02:10:22AM -0700, Russ Allbery wrote: But, in the example that you raise, this is an optional configuration. Indeed, at least at present and in all previous releases of Debian, one has to go out of one's way to get the lsb-invalid-mta package installed, since a fully functional mail transport agent providing the sendmail command is part of a standard Debian installation. You have to go out of your way to remove it. So the scenario I describe above doesn't really apply, and the problem reduces to whether the installation of the Debian lsb-core package should guarantee that a fully functional sendmail program is present on the system (but possibly not configured), as opposed to delivering one by default but allowing the local systems administrator to choose to replace it with a error-producing stub without removing the lsb-core package. I don't think there's any problem here wrt the LSB standard, but I'm not thrilled about the package-wise implementation of lsb-invalid-mta, particularly from the perspective of a Debian derivative which does not ship an MTA by default. - user installs a stock system with no MTA. - user installs lsb-core so they can install an LSB package - user installs a package that Depends: mail-transport-agent - user gets a system without a usable MTA, only because they installed lsb-core first I would argue that lsb-invalid-mta is a perfectly valid solution for lsb-core, but that it should not Provide: mail-transport-agent - so that any packages that actually say yes, I require an MTA get the default MTA and not the lsb-invalid-mta bodge. It's not reasonable for an LSB package which is at arm's length from the system to require a working and configured MTA, but for native packages I think this is legitimate - and installing the MTA by default does require the user to configure it for use. (It's probably also worth noting that Debian does not claim LSB compliance and the description of that Debian package states, rather prominently: The intent of this package is to provide a best current practice way of installing and running LSB packages on Debian GNU/Linux. Its presence does not imply that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant. So, really, it's kind of hard to see what's notably egregious about this.) Well, I think that package description is silly in its lawyeresque weaselness. The raison d'être of the package is to provide an LSB-compliant layer, which is what it means to support installing and running LSB packages. I don't see any reason the package description should have this long disclaimer about the possibility of bugs in the implementation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Steve Langasek vor...@debian.org writes: I don't think there's any problem here wrt the LSB standard, but I'm not thrilled about the package-wise implementation of lsb-invalid-mta, particularly from the perspective of a Debian derivative which does not ship an MTA by default. - user installs a stock system with no MTA. - user installs lsb-core so they can install an LSB package - user installs a package that Depends: mail-transport-agent - user gets a system without a usable MTA, only because they installed lsb-core first I would argue that lsb-invalid-mta is a perfectly valid solution for lsb-core, but that it should not Provide: mail-transport-agent - so that any packages that actually say yes, I require an MTA get the default MTA and not the lsb-invalid-mta bodge. Yeah, I agree with this, and also that lsb-core should actually depend on: default-mta | mail-transport-agent | lsb-invalid-mta to achieve this so that lsb-invalid-mta isn't the default choice. I think that's separate than the more general standards issue under discussion here (it still wouldn't prohibit the installation of lsb-core with lsb-invalid-mta), but I think that change would be a quality of implementation improvement in the LSB package. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
On Wed, Jul 10, 2013 at 12:08:00PM -0700, Russ Allbery wrote: I would argue that lsb-invalid-mta is a perfectly valid solution for lsb-core, but that it should not Provide: mail-transport-agent - so that any packages that actually say yes, I require an MTA get the default MTA and not the lsb-invalid-mta bodge. Yeah, I agree with this, and also that lsb-core should actually depend on: default-mta | mail-transport-agent | lsb-invalid-mta to achieve this so that lsb-invalid-mta isn't the default choice. I think that's separate than the more general standards issue under discussion here (it still wouldn't prohibit the installation of lsb-core with lsb-invalid-mta), but I think that change would be a quality of implementation improvement in the LSB package. If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all (or at least, there's no reason to label it an 'lsb' package). I think the purpose of the package is to let lsb-core be installed without automatically pulling in an MTA that has to be configured, and default-mta | mail-transport-agent | lsb-invalid-mta wouldn't achieve that. But I think dropping the Provides: from lsb-invalid-mta would. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Steve Langasek vor...@debian.org writes: If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all (or at least, there's no reason to label it an 'lsb' package). I think the purpose of the package is to let lsb-core be installed without automatically pulling in an MTA that has to be configured, and default-mta | mail-transport-agent | lsb-invalid-mta wouldn't achieve that. But I think dropping the Provides: from lsb-invalid-mta would. Ah, I see. Hm. I do think that the behavior a user most likely expects, when installing lsb-core, is to pull in a functional MTA. In other words, I think it's fine to provide a way for a sysadmin to select to not configure an MTA, but I do think that installing lsb-core should result in configuring an MTA by default. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
