Bug#466922: How to resolve critical situation
Hi, This whole issue started from the fix to Bug #465661 (m17n-db: binary-without-manpage usr/bin/m17n-db) because m17n-docs is non-free. The Debian Policy is: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1 --- Each program, utility, and function should have an associated manual page included in the same package. --- http://www.debian.org/doc/debian-policy/ch-scope.html --- In the normative part of this manual, the words must, should and may, and the adjectives required, recommended and optional, are used to distinguish the significance of the various guidelines in this policy document. Packages that do not conform to the guidelines denoted by must (or required) will generally not be considered acceptable for the Debian distribution. Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. Guidelines denoted by may (or optional) are truly optional and adherence is left to the maintainer's discretion. --- http://www.debian.org/doc/debian-policy/ch-archive.html#s-main --- In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) --- The non-conformance of a should guideline will generally be considered a bug. I think we have an exceptional case here where the binaries are Free and in one Debian package but the manpages are currently Non-free and in a separate Debian package, therefore we can *not* use Depends. Ian Jackson's (co-author of Debian Policy) comments: http://lists.debian.org/debian-devel/2008/02/msg01026.html --- I think the point of policy is to ensure the manpage exists, not to require that it be installed. I think Suggests is the right dependency. There is nothing wrong with installing a package without its documentation. --- cya, # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
On Tue, Mar 04, 2008 at 02:27:44PM +1100, Harshula wrote: Hi Osamu, I made a mistake and fortunately Joerg noticed it. The m17n-docs license contains a 'Cover Text' (hence considered not Free) and does not have the latex source that would be needed to create the PS and DVI files in usr/latex/. OK. Let's leave it in non-free. I've emailed the m17n developers and asked them whether it is possible for them to resolve these two issues. More importantly, how do we resolve your immediate needs? Could we ask for m17n-db 1.3.4-2 to be yanked from unstable and replaced with 1.3.4-1? Just use suggest in m17n-db as Ian said. That is all needed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi, On Mon, Mar 03, 2008 at 11:36:46PM +1100, Harshula wrote: Hi Ming, On Sun, 2008-03-02 at 11:10 -0600, Ming Hua wrote: Indirect build dependency. Scim-uim build-depends on libuim-dev, which depends on libm17n-dev, which depends on libm17n-0, which depends on m17n-db. Thanks for the info. I discussed the m17n intra-dependencies with upstream a few weeks ago: http://www.m17n.org/mlarchive/m17n-lib/200802/msg00011.html Please note he is using dependency as the library dependency. Debian dependency definitions are: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps When I update the m17n-lib Debian source package, I'm planning on libm17n to *not* depend on m17n-db. The next time I update the other m17n packages, I'm planning on using upstream's suggestions. As I understand Kenichi Handa's comment with assumption each package state: 1) m17n-lib (main) 2) m17n-db (main) 3) m17n-contrib (main) 4) m17n-docs (DSFG non-fee) Considering main package must not Depends: or Recommends: on non-free., I suggest: m17n-lib package Recommends: m17n-db ... since it is a strong, but not absolute. m17n-lib package Suggests: m17n-contrib ... since it is more useful with it (but not much as m17n-db) m17n-lib package Suggests: m17n-doc ... since it is more useful with it (provides manpage) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi, (I shortened CC list) On Mon, Mar 03, 2008 at 03:22:18AM +1100, Harshula wrote: Hi Osamu, First and foremost I have updated the m17n-docs source package and I've uploaded it to: http://sinhala.sourceforge.net/files/m17n/ There is one Lintian error with the manpages that I'm waiting to hear from upstream about before I decide how to fix it. Good. On Sun, 2008-03-02 at 23:53 +0900, Osamu Aoki wrote: Hi, This bug 466922 for m17n-db is blocking other packages such as scim-uim to build. Why? What's the relationship between scim-uim and m17n-db? scim-uim depends on one of the uim then it pulls in m17n-db. Pbuilder did not like broken package to be installed. (This may be minor issue. I will check. I have some second thought) I think we should attack this situation in 2 steps. Let's review situation: There was bug #465661 for m17n-db claiming binary-without-manpage usr/bin/m17n-db. This was based on policy 12.1 which states: Each program, utility, and function should have an associated manual page included in the same package. It is mere should whereas the basis of bug 466922 was policy 2.2.1 which states: In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package), Yes, this is serious policy bug. First, we should avoid serious bug if possible even with minor shortcoming. The correct thing to do is: 1. File bug to get unreasonable move to non-free (already done) 2. Just Suggest m17n-doc for now. (Once m17n-doc is back in main change it to depends if you think that is right thing). Really, it is only policy with should so Suggest may be enough. (at least to me. But I may be wrong) Dicussion on debian-devel: http://lists.debian.org/debian-devel/2008/02/msg00636.html Quick look tells me Ian (ex-DPL) said: I think the point of policy is to ensure the manpage exists, not to require that it be installed. I think Suggests is the right dependency. There is nothing wrong with installing a package without its documentation. This is quite conclusive. I agree moving m17n-doc to main is right thing. But the order of action should be carefully thought out. Please remove m17n-doc from depends now and set suggest. Since I have updated the m17n-doc source package, would it be better to upload that, even with the minor Lintian manpage errors? Yes. You are killing big problem. Close big bug and file new minor bug. (I did not check what exactly was problem, But manpage error warning are not that fatal as current situation.) Iwai-san, are you still active? Omote-san who seemed to uploaded his package, can you comment? This package seems practically orphaned. Considering 434044, Harshula should hijack m17n-doc package unless we get response from them in a week or so. I will be happy to see m17n-db maintainer taking charge of all related packages. I already announced ITH back in November 2007: http://lists.debian.org/debian-devel/2007/11/msg00440.html Good. Let's do it now. I was quite surprized by the non-free move. GFDL without invariant section seems to be OK to be in main. I suspect it happened before the 2006 Debian vote on the issue. I heard but that was not right mov then either. Osamu PS: The upload to main may need to happen after requesting removal of current non-free one. What's the procedure for that? I do not know exactly. Ask debian-mentor for this sitution. (I have not encountered such case yet.) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi Ming, On Sun, 2008-03-02 at 11:10 -0600, Ming Hua wrote: Indirect build dependency. Scim-uim build-depends on libuim-dev, which depends on libm17n-dev, which depends on libm17n-0, which depends on m17n-db. Thanks for the info. I discussed the m17n intra-dependencies with upstream a few weeks ago: http://www.m17n.org/mlarchive/m17n-lib/200802/msg00011.html When I update the m17n-lib Debian source package, I'm planning on libm17n to *not* depend on m17n-db. The next time I update the other m17n packages, I'm planning on using upstream's suggestions. cya, # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi Osamu, On Mon, 2008-03-03 at 21:07 +0900, Osamu Aoki wrote: Dicussion on debian-devel: http://lists.debian.org/debian-devel/2008/02/msg00636.html Quick look tells me Ian (ex-DPL) said: I think the point of policy is to ensure the manpage exists, not to require that it be installed. I think Suggests is the right dependency. There is nothing wrong with installing a package without its documentation. This is quite conclusive. I didn't weight the opinions, but the opinion tally seemed to be: Depends: 3 Recommmend: 1 Suggest: 1 I already announced ITH back in November 2007: http://lists.debian.org/debian-devel/2007/11/msg00440.html Good. Let's do it now. http://ftp-master.debian.org/new/m17n-docs_1.5.0-1.html cya, # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi Osamu, I made a mistake and fortunately Joerg noticed it. The m17n-docs license contains a 'Cover Text' (hence considered not Free) and does not have the latex source that would be needed to create the PS and DVI files in usr/latex/. I've emailed the m17n developers and asked them whether it is possible for them to resolve these two issues. More importantly, how do we resolve your immediate needs? Could we ask for m17n-db 1.3.4-2 to be yanked from unstable and replaced with 1.3.4-1? cya, # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi, This bug 466922 for m17n-db is blocking other packages such as scim-uim to build. I think we should attack this situation in 2 steps. Let's review situation: There was bug #465661 for m17n-db claiming binary-without-manpage usr/bin/m17n-db. This was based on policy 12.1 which states: Each program, utility, and function should have an associated manual page included in the same package. It is mere should whereas the basis of bug 466922 was policy 2.2.1 which states: In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package), Yes, this is serious policy bug. First, we should avoid serious bug if possible even with minor shortcoming. The correct thing to do is: 1. File bug to get unreasonable move to non-free (already done) 2. Just Suggest m17n-doc for now. (Once m17n-doc is back in main change it to depends if you think that is right thing). Really, it is only policy with should so Suggest may be enough. (at least to me. But I may be wrong) I agree moving m17n-doc to main is right thing. But the order of action should be carefully thought out. Please remove m17n-doc from depends now and set suggest. Iwai-san, are you still active? Omote-san who seemed to uploaded his package, can you comment? This package seems practically orphaned. Considering 434044, Harshula should hijack m17n-doc package unless we get response from them in a week or so. I will be happy to see m17n-db maintainer taking charge of all related packages. I was quite surprized by the non-free move. GFDL without invariant section seems to be OK to be in main. Osamu PS: The upload to main may need to happen after requesting removal of current non-free one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
Hi Osamu, First and foremost I have updated the m17n-docs source package and I've uploaded it to: http://sinhala.sourceforge.net/files/m17n/ There is one Lintian error with the manpages that I'm waiting to hear from upstream about before I decide how to fix it. On Sun, 2008-03-02 at 23:53 +0900, Osamu Aoki wrote: Hi, This bug 466922 for m17n-db is blocking other packages such as scim-uim to build. Why? What's the relationship between scim-uim and m17n-db? I think we should attack this situation in 2 steps. Let's review situation: There was bug #465661 for m17n-db claiming binary-without-manpage usr/bin/m17n-db. This was based on policy 12.1 which states: Each program, utility, and function should have an associated manual page included in the same package. It is mere should whereas the basis of bug 466922 was policy 2.2.1 which states: In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package), Yes, this is serious policy bug. First, we should avoid serious bug if possible even with minor shortcoming. The correct thing to do is: 1. File bug to get unreasonable move to non-free (already done) 2. Just Suggest m17n-doc for now. (Once m17n-doc is back in main change it to depends if you think that is right thing). Really, it is only policy with should so Suggest may be enough. (at least to me. But I may be wrong) Dicussion on debian-devel: http://lists.debian.org/debian-devel/2008/02/msg00636.html I agree moving m17n-doc to main is right thing. But the order of action should be carefully thought out. Please remove m17n-doc from depends now and set suggest. Since I have updated the m17n-doc source package, would it be better to upload that, even with the minor Lintian manpage errors? Iwai-san, are you still active? Omote-san who seemed to uploaded his package, can you comment? This package seems practically orphaned. Considering 434044, Harshula should hijack m17n-doc package unless we get response from them in a week or so. I will be happy to see m17n-db maintainer taking charge of all related packages. I already announced ITH back in November 2007: http://lists.debian.org/debian-devel/2007/11/msg00440.html I was quite surprized by the non-free move. GFDL without invariant section seems to be OK to be in main. I suspect it happened before the 2006 Debian vote on the issue. Osamu PS: The upload to main may need to happen after requesting removal of current non-free one. What's the procedure for that? Thanks, # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466922: How to resolve critical situation
On Mon, Mar 03, 2008 at 03:22:18AM +1100, Harshula wrote: On Sun, 2008-03-02 at 23:53 +0900, Osamu Aoki wrote: This bug 466922 for m17n-db is blocking other packages such as scim-uim to build. Why? What's the relationship between scim-uim and m17n-db? Indirect build dependency. Scim-uim build-depends on libuim-dev, which depends on libm17n-dev, which depends on libm17n-0, which depends on m17n-db. Ming 2008.03.02 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
