Bug#69229: PROPOSED 2000/08/16] Free pkgs depending on non-US should go into non-US/{main,contrib}
On Wed, Aug 16, 2000 at 08:04:00PM +1000, Anthony Towns wrote: The principle: packages that are DFSG-free, depend on packages in non-US/main, but are otherwise candidates for main should go into non-US/main also. That way they're still a part of the official distribution, but they don't come up as uninstallables for the poor deprived US folks. Here's a sample wording change. It incorporates the accepted change from #62946. It's not entirely clear where contrib packages that don't include crypto, but Depend: on software that does (from non-US/*) would go in the following, probably. [..] Seconded. -- Joseph Carter [EMAIL PROTECTED] GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 Knghtbrd you know, Linux needs a platform game starring Tux Knghtbrd kinda Super Marioish, but with Tux and things like little cyber bugs and borgs and that sort of thing ... Knghtbrd And you have to jump past billgatus and hit the key to drop him into the lava and then you see some guy that looks like a RMS or someone say Thank you for rescuing me Tux, but Linus Torvalds is in another castle!
Bug#69229: [PROPOSED 2000/08/16] Free pkgs depending on non-US should go into non-US/{main,contrib}
On Wed, Aug 16, 2000 at 08:04:00PM +1000, Anthony Towns wrote: A dependency on non-us will also land a package in contrib. I think there was a proposal to change that, so that packages which depend on packages in non-US/main remain in non-US/main. Actually, there doesn't seem to be such a proposal; there just seems to be your (accepted) proposal to make both main and non-US/main part of the Debian distribution. So, let's fix that. The principle: packages that are DFSG-free, depend on packages in non-US/main, but are otherwise candidates for main should go into non-US/main also. That way they're still a part of the official distribution, but they don't come up as uninstallables for the poor deprived US folks. Here's a sample wording change. It incorporates the accepted change from #62946. It's not entirely clear where contrib packages that don't include crypto, but Depend: on software that does (from non-US/*) would go in the following, probably. Seconded! -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#62378: Redundant directory and package name
[EMAIL PROTECTED] (Josip Rodin) wrote on 15.04.00 in [EMAIL PROTECTED]: On Sat, Apr 15, 2000 at 03:14:07AM +0300, Eray Ozkural wrote: The RFC docs currently reside under /usr/doc/doc-rfc. The second doc is redundant, which is also part of the package name. It should be fixed to be using /usr/share/doc/rfc Are you familiar with debian policy? I doubt it, since debian policy requires a package install docs in /usr/share/doc/literal-unmangled-package-name No, I'm not that familiar with the debian policy. Though I'm quite familiar with common sense for about 20 years; I would then suggest that the package name is redundant. If it is in the doc section, it doesn't have to be named doc-rfc, it should simply be named rfc and then it would reside under /usr/share/doc/rfc and become perfectly compliant with the debian policy. No, the directory containing copyright and changelog* files must be called /usr/share/doc/doc-rfc if the package is called doc-rfc, that is our policy. However, actual RFCs can be moved elsewhere, for example, like the HOWTOs and the FAQs, in /usr/share/doc/RFC/? 1. I see no reason to rename the package. Doc-only packages are usually named X-doc[-format] if they are for X, and doc-X when they're standalone. doc-rfc is no exception here. 2. Moving te actual RFCs is certainly an option. What does this group think? MfG Kai
Re: Bug#62378: Redundant directory and package name
On Sun, Aug 20, 2000 at 04:37:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Josip Rodin) wrote on 15.04.00 in [EMAIL PROTECTED]: On Sat, Apr 15, 2000 at 03:14:07AM +0300, Eray Ozkural wrote: The RFC docs currently reside under /usr/doc/doc-rfc. The second doc is redundant, which is also part of the package name. It should be fixed to be using /usr/share/doc/rfc Are you familiar with debian policy? I doubt it, since debian policy requires a package install docs in /usr/share/doc/literal-unmangled-package-name No, I'm not that familiar with the debian policy. Though I'm quite familiar with common sense for about 20 years; I would then suggest that the package name is redundant. If it is in the doc section, it doesn't have to be named doc-rfc, it should simply be named rfc and then it would reside under /usr/share/doc/rfc and become perfectly compliant with the debian policy. No, the directory containing copyright and changelog* files must be called /usr/share/doc/doc-rfc if the package is called doc-rfc, that is our policy. However, actual RFCs can be moved elsewhere, for example, like the HOWTOs and the FAQs, in /usr/share/doc/RFC/? 1. I see no reason to rename the package. Doc-only packages are usually named X-doc[-format] if they are for X, and doc-X when they're standalone. doc-rfc is no exception here. 2. Moving te actual RFCs is certainly an option. What does this group think? /usr/share/rfc/ Makes more sense to me. I don't see a problem with the package name. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Bug#62378: Redundant directory and package name
On Sun, 20 August 2000 11:19:44 -0400, Ben Collins wrote: 2. Moving te actual RFCs is certainly an option. What does this group think? /usr/share/rfc/ Makes more sense to me. I don't see a problem with the package name. Same here. Alexander
there are different variables mentioned in the footnote about debugging and stripping binaries
Hi, The footnote of the section I just filed a bug about says: Rationale: Building by default with -g causes more wasted CPU cycles since the information is stripped away anyway. The package can by default build without -g if it also provides a mechanism to easily be rebuilt with debugging information. This can be done by providing a build-debug make target, or allowing the user to specify BUILD_DEBUG=yes in the environment while compiling that package. I don't get it. Which is it, then, BUILD_DEBUG=yes or DEB_BUILD_OPTIONS=debug ? And... * There will be much less wasted cpu time for the autobuilders since not having debugging information (and hence also not having to strip it) will increase the speed of compiles. This skips an entire pass of the compiler, That last character should be a full-stop, or is there text missing after it? -- Digital Electronic Being Intended for Assassination and Nullification
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
Package: debian-policy Version: 3.2.0.0 Hi, Section `4.1 Binaries' says: CFLAGS = -O2 -Wall INSTALL = install ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL += -s endif endif The second ifneq needs to be ifeq. Furthermore, I think this form would be a bit more readable: ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g endif ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif Or even: ifeq $(findstring debug,$(DEB_BUILD_OPTIONS)) debug CFLAGS += -g endif ifneq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) nostrip INSTALL += -s endif Or a combination :) Pick whichever people find nicest, as long as the logic is correct. -- Digital Electronic Being Intended for Assassination and Nullification
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote: Now that potato has been released, I propose that we start deprecating the /usr/doc compatibility symlinks, at the same time we make using /usr/share/doc a nearly-release-goal for woody. I think an addendum is needed to this proposal -- if any package *has* had symlinks in /usr/doc, then it needs to clean them up in its install scripts, now, and possibly forever. This is one of the reasons I objected to the symlinks in the first place -- now a *whole* bunch of packages are going to have to carry extra cruft for an indefinite period of time -- but since we went ahead and implemented the symlinks, we damn well better be willing to pay the price. Without such an addendum, I object to this proposal. With it, I will second. Personally, I think one of the people who crammed the symlink idea through should be forced to do the work of creating the proper patches to policy (and maybe to debhelper). Santiago and I (in a rare point of agreement) tried to prevent this mess. We failed, but we shouldn't be forced to clean it up now. cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into | this .signature file.
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
On Sun, 20 Aug 2000, Chris Waters wrote: I think an addendum is needed to this proposal -- if any package *has* had symlinks in /usr/doc, then it needs to clean them up in its install scripts, now, and possibly forever. This is one of the reasons I objected to the symlinks in the first place -- now a *whole* bunch of packages are going to have to carry extra cruft for an indefinite period of time -- but since we went ahead and implemented the symlinks, we damn well better be willing to pay the price. Without such an addendum, I object to this proposal. With it, I will second. Personally, I think one of the people who crammed the symlink idea through should be forced to do the work of creating the proper patches to policy (and maybe to debhelper). Santiago and I (in a rare point of agreement) tried to prevent this mess. We failed, but we shouldn't be forced to clean it up now. Current policy says: Former Debian releases placed all additional documentation in `/usr/doc/package'. To realize a smooth migration to `/usr/share/doc/package', each package must maintain a symlink `/usr/doc/package' that points to the new location of its documentation in `/usr/share/doc/package'[1]. The symlink must be created when the package is installed; it cannot be contained in the package itself due to problems with `dpkg'. One reasonable way to accomplish this is to put the following in the package's `postinst': if [ $1 = configure ]; then if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \ -a -d /usr/share/doc/#PACKAGE# ]; then ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE# fi fi And the following in the package's `prerm': if [ \( $1 = upgrade -o $1 = remove \) \ -a -L /usr/doc/#PACKAGE# ]; then rm -f /usr/doc/#PACKAGE# fi That means it's already a bug if a package doesn't remove this link in it's prerm. (And lintian gives you a warning if you forget this.) If policy is changed and the symlink is no longer necessary you can simply remove these statements from the postinst and the prerm and the package doesn't has to carry any extra cruft in the future. cheers cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
On Sun, Aug 20, 2000 at 11:31:32AM -0700, Chris Waters wrote: On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote: Now that potato has been released, I propose that we start deprecating the /usr/doc compatibility symlinks, at the same time we make using /usr/share/doc a nearly-release-goal for woody. I think an addendum is needed to this proposal -- if any package *has* had symlinks in /usr/doc, then it needs to clean them up in its install scripts, now, and possibly forever. Huh? This is already handled by the packages' prerm scripts. If future versions of packages don't do *anything at all about the symlinks* they'll still be removed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpxKxVukziWt.pgp Description: PGP signature
Bug#69426: PATCH] typos and awkwardness in policy.sgml
Hi, Thanks. I just edited the policy docs, and shall upload to CVS soon. manoj -- A fractal is by definition a set for which the Hausdorff Besicovitch dimension strictly exceeds the topological dimension. Mandelbrot, The Fractal Geometry of Nature Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
On Sun, Aug 20, 2000 at 08:56:29PM +0200, Adrian Bunk wrote: [re: getting rid of symlinks in /usr/doc] That means it's already a bug if a package doesn't remove this link in it's prerm. Ah, so it is. Good point. In that case, I withdraw my objection and second Santiago's original proposal. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into | this .signature file. pgpBcdMmojXIs.pgp Description: PGP signature
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g endif ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif The nostrip check needs to be inside the debug check. Because of you are not compiling with debugging turned on, there's no reason to not strip the binaries. So (note, the blank should go first): ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif endif Also, I think Joey is likely to add nostrip detection to dh_strip, which means for packages that use that, they wont need to detect the nostrip option. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Bug#69424: [PATCH] typos in menu-policy.sgml
Matt Kraai [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: There are a few misspellings in menu-policy.sgml. The following patch fixes them. Correction to the patch: --- menu-policy.sgml.orig Sat Aug 19 08:20:22 2000 +++ menu-policy.sgml Sat Aug 19 08:21:31 2000 @@ -12,8 +12,8 @@ 2 or (at your option) any later. The debian-policy mailing list has taken responsibility for the - contents of this document8, with the package maintainers responsible - for packagingn adminstrivia only. + contents of this document, with the package maintainers responsible + for packaging adminstrivia only. That should be packaging administrivia. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
On Sun, Aug 20, 2000 at 04:24:09PM -0400, Ben Collins wrote: ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g endif ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif The nostrip check needs to be inside the debug check. Because of you are not compiling with debugging turned on, there's no reason to not strip the binaries. Same difference... So (note, the blank should go first): I see no reason why, it works just fine when it's second. And it's more alike to the human way of thinking (`if string equals nothing' compared to `if nothing equals string'). :) Also, I think Joey is likely to add nostrip detection to dh_strip, which means for packages that use that, they wont need to detect the nostrip option. Yes, that would be useful. Although, the makefiles of individual packages should still need to be checked, some of them do stripping automatically. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Bug#69311: [PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
Santiago Vila wrote: Now that potato has been released, I propose that we start deprecating the /usr/doc compatibility symlinks, at the same time we make using /usr/share/doc a nearly-release-goal for woody. Have you read http://lists.debian.org/debian-ctte-9909/msg00023.html and http://www.debian.org/Lists-Archives/debian-ctte-9908/msg00038.html lately? Quoting the Tech Committee's decision: | 1. Policy 3.X mandates that packages that move the docs to | /usr/share/doc must provide a compatibility symlink in /usr/doc. | This shall allow packages to incrementally move to policy 3.X, | while providing compatibility with older systems. | (/usr/doc/package symlink is handled by package) | | Thus, potato ships with a full /usr/doc/ (some of which is symlinks), | and a partial /usr/share/doc. This is where we are now. And I stress that the transition is currently *incomplete*: [EMAIL PROTECTED]:/usr/doccat /etc/debian_version woody [EMAIL PROTECTED]:/usr/docfind . -maxdepth 1 -type d |wc -l 187 [EMAIL PROTECTED]:/usr/docfind /usr/share/doc -maxdepth 1 -type d |wc -l 961 |2. Post potato, we continue the transition, with the symlinks in |place. Before freeze, we file important bugs against any |package that has not been moved over (in one and a half |release periods, we may be actually able to accomplish this), |with NMU-fests to bring over the others. We seem to be well on our way to accomplishing this for woody, with about 83% of packages converted. | Thus, potato+1 (woody) ships with a full /usr/share/doc, and a | /usr/doc full of symlinks. | |3. At a later date, another policy (say, 4.X) shall ask for | packages to no longer provide the link (and possibly remove | links from /usr/doc). We can also provide a script (possibly | in base-files postinst) that rm's symlinks from within | /usr/doc. woody+1 may ship with such a script. (there was a | proposal as well that potato+2 (woody+1) ships with just the | prerms, and not the base file script, and potato+3 ships | with the base-file script, but I am not sure this long a | reversion period is required). I have to object to efforts to change and short-circuit the Tech Committee's decision. I also really hate reopening this whole issue. Can we just not follow the plan we went through so much trouble to agree on in the first place? -- see shy jo
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
On Mon, Aug 21, 2000 at 12:10:37AM +0200, Josip Rodin wrote: On Sun, Aug 20, 2000 at 04:24:09PM -0400, Ben Collins wrote: ifneq $(findstring debug,$(DEB_BUILD_OPTIONS)) CFLAGS += -g endif ifeq $(findstring nostrip,$(DEB_BUILD_OPTIONS)) INSTALL += -s endif The nostrip check needs to be inside the debug check. Because of you are not compiling with debugging turned on, there's no reason to not strip the binaries. Same difference... Not really. Seperating them does not show their relationship. Obviously nostrip is useless unless you have debugging turned on. The example is correct in how it did this, and that much should not change. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
Ben Collins wrote: The nostrip check needs to be inside the debug check. Because of you are not compiling with debugging turned on, there's no reason to not strip the binaries. So (note, the blank should go first): Wow, you almost overloaded my negation parser there. BTW, the paragraph in policy about DEB_BUILD_OPTIONS is poorly worded and has some grammatical problems. I've marked the parts that got on my nerves. Debugging symbols are useful for error diagnosis, investigation of core dumps (which may be submitted by users in bug reports), or testing and developing the software. Therefore it is recommended to support building the package with debugging information through the following interface: If the environment variable `DEB_BUILD_OPTIONS' contains the string `debug', compile the software with debugging information (usually this involves adding the `-g' flag to `CFLAGS'). This allows to generate a build tree with debugging information. If the environment variable `DEB_BUILD_OPTIONS' contains the string `nostrip', do not strip the files at installation time. This allows ^^^ to generate a package with debugging information included. The ^ following makefile snippet is only an example how to test for either ^^^ condition: [1] I think that should be This allows something. And example how to test is missing an of. There are also format errors in the .txt version of policy in bulletted list in the rationalle. Also, I think Joey is likely to add nostrip detection to dh_strip, which means for packages that use that, they wont need to detect the nostrip option. Done. -- see shy jo
Bug#69487: the example for using nostrip in DEB_BUILD_OPTIONS is incorrect
On Sun, Aug 20, 2000 at 04:40:10PM -0700, Joey Hess wrote: BTW, the paragraph in policy about DEB_BUILD_OPTIONS is poorly worded and has some grammatical problems. I've marked the parts that got on my nerves. [...] This allows to generate a build tree with debugging information. If the environment variable `DEB_BUILD_OPTIONS' contains the string `nostrip', do not strip the files at installation time. This allows ^^^ to generate a package with debugging information included. The ^ following makefile snippet is only an example how to test for either ^^^ I think that should be This allows something. And example how to test is missing an of. I agree; this is rotten grammar. Another popular, but utterly wrong, construct that is annoying is following needs with a verb form other than the infinitive or present perfect. E.g. This needs doing. is correct (if perhaps a bit colloquial). This needs to be done. is also correct. This needs done. is NOT correct. This type grammar allows to not comprehend English correctly. People needs learned do better. -- G. Branden Robinson |The first thing the communists do when Debian GNU/Linux|they take over a country is to outlaw [EMAIL PROTECTED] |cockfighting. http://www.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgpLMtb08HYpr.pgp Description: PGP signature
Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.
Hi, I think I must object to this proposal. I think nothing good can come out of this hastening of the planned transition; espescially since no good reaso is given as to why we must sccelrate the transition process. What is wrong with the plan currently in place? manoj -- You're ugly and your mother dresses you funny. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
CVS srivasta: Added must/should/may stuff, typo fixes in the policy and rules files, as well as updating the symlink before lib handling in dpkg language
CVSROOT:/cvs/debian-policy Module name:debian-policy Changes by: srivastaSun Aug 20 18:16:28 PDT 2000 Modified files: . : packaging.sgml policy.sgml debian : rules Added files: debian : .cvsignore Log message: Added must/should/may stuff, typo fixes in the policy and rules files, as well as updating the symlink before lib handling in dpkg language
