Bug#970234: consider dropping "No hard links in source packages"
Hello Helmut On 12.10.2020 19:30, Helmut Grohne wrote: You appear to be talking about binary packages. This bug is about source packages. When you unpack a source package, you are creating a directory hiearchy rooted at the point where you start unpacking. There is not possibly any reasonable way to split your source package into multiple file systems. This is very different from binary packages where the underlying hiearchy is shared with other packages and directories frequently already exist. Your are totally right. And it is also on the subject line. So: I have not reasonable explanation. ciao cate
Bug#970234: consider dropping "No hard links in source packages"
On 12.10.2020 16:22, Andrey Rahmatullin wrote: On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote: Now we are more strict on where we can split filesystems What do you mean? If I remember correctly, now we do not support / and /usr to be on a different filesystems, and I think there were few other corner cases which were forbidden. ciao cate
Bug#970234: consider dropping "No hard links in source packages"
On 13.09.2020 12:52, Helmut Grohne wrote: Package: debian-policy Version: 4.5.0.3 Severity: wishlist Jakub stumbled into the "No hard links in source packages" requirement added around 1996 and couldn't make sense of it. Neither could Christoph nor myself. tar does support hard links just fine. lintian does not check this property. sugar-log-activity/38 is an example package violating the property. It is shipped in buster and technically rc-buggy though no bug is filed about it. I believe that the requriement needs a rationale. Failing that, it should be dropped. The rationale was probably similar so symlinks: they may fail across different filesystems, and we supported to have e.g. / /usr /usr/share /usr/local /var (and various /var/*) /home /tmp /boot etc on different file systems. Now we are more strict on where we can split filesystems (and disk are larger, and LVM simplified much of filesystem handling). I think a hardlink on same directory should be fine, or within directories which must be on the same filesystem. ciao cate [for symlinks we have the problem with relative links (containing "../") passing filesystem boundaries]
Re: Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Manoj Srivastava wrote: On Thu, Jun 04 2009, Giacomo Catenazzi wrote: I think we could forbid echo -n on maintainer and other scripts, but allow it on init.d scripts. Rationale: - portability is more important on other scripts, and it is also not so frequent to use echo -n - init.d are system scripts which special requirement, so they are not portable. And we could ev. workaround with a special alias/path which set a non-portable echo. This is also simple because init.d scripts sould be called only by/via few programs/ I am kinda missing the rationale for the policy change here. At this point, forbidding it in one palce and not the other would not make life any easier for shells that want to be in /etc/shells, and making a policy change seems mostly random churn to me. Yes, echo -n maybehave differently in different shells, and it is undefined in POSIX, perhaps, but all shells in Debian have a specific interpretation of -n that all scripts may rely on. Yes, You are right. On programs (i.e. in PATH) I think portability is more important (and within POSIX domain), but init.d script have a more controllable environment. But I agree, it is not good to distinguish cases. Is there a compelling reason to change policy? If so, what is it? From the report, it seems like more of a dev-ref thing; recommending some practice is better than others for portability. I am not seeing yet why this belongs in policy and not dev-ref. I agree. I don't like the change echo -n to printf, I don't think it is the right thing to do. I think also in this case we must do standardization from common use. So recommending more portable scripts in dev-ref is good. I really thing that if policy will do something in this field, will be mandating the use of common helpers (lsb, possibly colored, ...), but before we (DD, DM, ...) must have a proven common base. Yes, printf. It is not an alternative: - It is ugly This is mostly irrelevant. If it is technically superior, it would not matter if it offends your sense of aesthetics; it might not offend other people. Technically you are right, but more I see in other standard bodies, the more I see that aesthetic is a *must* for standard. Standards are void if nobody use them. As I see the most ugly standards are also the less used. The most ugly part of existing standards are also the less used, also if they are technically superior (C99 suffered from this). So a solution should be aesthetically and technically good, to force users to change code. For this reason I think helper functions will be the right things: they have more functionality (allowing to skip parts, colour for young users), but easy to use and to read. [But they will never follow actual LSB. In this field it was silly (return codes, names, ...)] - it is not on root partition Point. The ugly part it is IMHO the most important part. Most of people understand echo -n, but I don't know if all people understand fully printf. Mixing echo and printf is ugly. People who can't learn something as simple as printf should not be allowed to write maintainer scripts or init scripts. I think they can't learn, but it different to: they use correctly or simply they will use it. Someone told the printf is common in some languages (C, shell, python,...), but this is also a disadvantage: there are subtle (and also not so subtle) differences, which port to bugs and misunderstandings. Unfortunately not all developers are always good developers, which check carefully code with the right manuals easy accessible. A good point of new C standardization effort: to try to avoid at language/compiler level security errors from lazy coders. ciao cate manoj -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Geissert wrote: On Tuesday 02 June 2009 12:54:00 Bill Allombert wrote: [...] It does not make sense to policy to discourage echo -n. Policy could deprecate it in favor of something else, but I do not see any alternative mentioned in this bug report, and otherwise discouraging echo -n would amount to discourage shell scripts to display lines that does not end by a newline, while Policy 9.4. mandates that init scripts display Starting foo without an ending newline. Furthermore, adding vague recommendation to policy is a waste of resource. So, is there an alternative to echo -n that you would like to recommends, and are you willing to do the job to make sure that all Debian sh-compliant shells in Debian support it ? I think we could forbid echo -n on maintainer and other scripts, but allow it on init.d scripts. Rationale: - portability is more important on other scripts, and it is also not so frequent to use echo -n - init.d are system scripts which special requirement, so they are not portable. And we could ev. workaround with a special alias/path which set a non-portable echo. This is also simple because init.d scripts sould be called only by/via few programs/ Yes, printf. It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Most of people understand echo -n, but I don't know if all people understand fully printf. Mixing echo and printf is ugly. Anyway the standard are helper tools, not tools to make difficult the live of user and maintainer. See for example the recent discussion about ext3, see the old discussion about tar (tar is not in POSIX, people should use 'pax') BTW I think this is incorrect: $ POSIXLY_CORRECT=1 bash -c echo -n line one; echo line two; line oneline two ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Better formatting for long descriptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: - Ability to recognize and render the following logical entities, in decreasing order of importance: + unordered lists + ordered lists really needed? + emphasis + strong emphasis + definition lists + hypertext links + underlines, and strike throughs I don't think they are needed. Underlines is generally bad, strike throughs are worse ;-) Ev. also monospace, e.g. for commands, but I really prefer to have a simpler language as possible. At this point, I would say that Markdown/Resstructued text meets most of the goals above, as long as we restrict the markup to the list above: Could provide us an example of Resstructued for the basic constructs? * unordered lists * ordered lists * emphasis * strong emphasis * definition lists * hypertext links * underlines, and strike throughs I like also creole (standardized wiki language, moinmoin support it), but no definition lists, underline, strike throughs. So for creole: * unordered lists \n * \n ** * ordered lists \n # \n ## * emphasis //foo// * strong emphasis **bar** * definition lists missing ev. \n **spam** is spam * hypertext links normal url * underlines, and strike throughs missing, missing ciao cate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknnhU8ACgkQ+ZNUJLHfmlfJigCfR/Jpn96l7FxHb9INlJlHkd+S z+MAn2eM+rOOHN9n8LJTYXi/gT7cWuMa =3a5+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Steve Langasek wrote: On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote: Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one provider, or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. From the definition of the virtual package in question, it should have only one provider at a time. And this is an exception, which I want to avoid. So let try to work around with normal package. If we fail, I agree with the virtual package. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. This unavoidably couples Debian's choice of a default MTA for users who install the new release, to the behavior for users who are upgrading from a previous release, because users who have such a 'default-mta' package installed will find their MTA changed on dist-upgrade. What about an other level of indirection: package debian-mta: Depends: exim | mta-mail-transfer-agent I think this case will solve upgrades, and changing easily the mta (without causing a failed dependency). ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. The reasons for which it should be removed are: * /etc/init.d/rc has not supported this for an extremely long time, probably never, because the system would be unbootable due to .sh scripts calling 'exit' [0, 1]. Given this, I definitely agree. There's no point in having a statement like this in Policy when our core packages don't implement it and no one has apparently cared. Unless someone steps up to say that we should do the work to reimplement support for this interface (including fixing all the broken *.sh scripts we have now), I think it's obvious we should simply remove it. There's no need to specify things no one uses and clearly can do without. I agree. BTW LSB doesn't have such special case, so such proposal will converge to LSB, which is also positive. ciao cate -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495233: debian-policy: README.source content should be more detailed
Lucas Nussbaum wrote: First, section 4.14 should list things that one does not need to describe in debian/README.source. For example, the use of one of the standard patch systems (quilt, dpatch, simple-patchsys) doesn't need to be documented, since every NMUer should be able to work with them. Another example is build systems: cdbs is used by 20% of our packages, so I don't think that one need to document its use. I think the better way is do it similar to copyright: for common patch/build system we should include only a link to the relative document. Maybe on a common package (build essential or dpkg-dev) or on patch system package (but in this case we should push stronger the maintainer to include the relevant informations). BTW debian/README.source is not only for the MNUer, but also for our users, so I prefer redundant documentation. Also, it would be interesting to extend the use of debian/README.source to other areas, such as: - whether the maintainer encourages commits for other people directly to the package's VCS. - the branch layout in the package's VCS. I agree with that. PS: you should provide a patch! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
Lionel Elie Mamane wrote: (Further discussion should happen on [EMAIL PROTECTED], but please CC me.) During Manoj's policy talk at DebConf8, Gerfried opened the subject of the policy's stand on relative and absolute symlinks, which currently is absolute if going through top-level, relative otherwise. I wanted to give another data-point: Mailman switched its intra-/var/ symlinks to be absolute, because relative symlinks there broke setups of people that moved their /var/lib/mailman/ directory to another partition, not through mounting, but through replacing their /var/lib/mailman/ directory by a symlink to elsewhere - e.g. /u/mailman . This broke e.g. relative symlinks /var/lib/mailman/log to ../../logs/mailman. Bugs #413604 and #408855 contain the whole story. As policy doesn't technically *mandate* relative symlinks, but says in general, we felt we could deviate from our own initiative. I must say I don't quite see in what scenario relative symlinks make something work that absolute symlinks do not make work. So, is there any reason at all to use relative symlinks? I think it was done for efficiency, but I think correctness is more important. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary
Steve Langasek wrote: On Thu, Jun 05, 2008 at 06:25:14PM +0200, Giacomo A. Catenazzi wrote: Manoj Srivastava wrote: Hi, On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg [EMAIL PROTECTED] said: Policy section 3.8, about essential packages, doesn't explain when/why essential is neccessary, only that it should not be essential if it's not necessary. My understanding is that a package is Essential if without it is impossible to install any more packages to the system -- that is, the package is required for proper functioning of dpkg. If my understanding is correct, it should be easy to add in a line about when packages can be made Essential. In addition Essential is also used not full dependencies with obvious packages. (Policy 3.5) This is not part of the rationale for a package's inclusion in Essential, it's an effect of a package's inclusion in Essential. Packages should only be in the Essential set if they have to be there to guarantee the operation of dpkg. I'm not so sure. Or better, I agree the first paragraph (a package will become Essential if it is need by dpkg), but I really think that the second part it is wrong: I don't think we should remove easily the essential status from a package. Packages expect essential package to be installed, without requiring dependencies, so a lot of package will broke on removal of some essential. I think policy should include a incomplete list of essential package, because of the side effect (no dependencies on essential package). ciao cate Note: From Klecker ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50832 ): [1] Essential means that the package does not need to be depended on (essential does not seem to be guaranteed to work for implicit Pre-Depends), however the thing that bash provides that is essential is /bin/sh. (...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New policy
Hello list! I followed Manoj talk at DebConf7, and I would like to help. I'm trying to find and write down some idea, but they inevitably give me some questions: 1- Is available already a starting document? 2- some guidelines about docbook? 3- what is the scope? It should be like actual document, a technical description of debian packages, or it should include also the social contract, the DD behaviour about bugs, ... I think it is difficult to split the two part (DD GPG-keys in packages; severity of bugs affect the priority of packages; changelog, ...) But OTOH, it will be a more difficult and long project. 4- It should be Debian specific or split into neutral and debian part? IMHO we are debian, so we should document debian, but it will pitty if Ubuntu and other organization will use a different (and probably not updated) version of .deb I like that RPM is pretty distribution neutral. OTHO if it can be used externally will complicate the policy process, it should be open to third parties, and it will complicate the live of DD (informations are split into two part) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
