Re: does /var/games have to be deleted on purge? (if it's empty..)
On Sun, Jan 03 2010, Russ Allbery wrote: Should we add a section to Policy somewhere that explains the package states I think that patch of mine that added the pretty pictures of transitions and states had some language about package states, taken from dpkg. and what the requirements of a package are around preserving or removing its data other than log files and configuration files on purge? If so, that would be the relevant place to talk about whether or not directories like /var/games should be removed when empty (and similarly /var/games/package, /var/lib/package, etc.). I think policy is currently vague about this since perhaps such a decision ought to be made on a case by case basis? I can certainly see the difference in preservation of data and state information for a RDBMS package as being different from that of a game which is different still from a clock program. Can we be certain that the distribution is best served by a one size fits all policy here? manoj -- Virginia law forbids bathtubs in the house; tubs must be kept in the yard. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: use README.source to describe whether committing to VCS is desired
On Wed, Dec 23 2009, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: On Wed, Dec 23, 2009 at 11:41:07PM +0900, Charles Plessy wrote: + p + In addition, filedebian/README.source/file may also be ^^^ I'd rather use should if, as it seems from the few early messages, there is consensus on this change. + used to describe how a source package is managed by its + maintainers, for instance by detailing the write permissions + on the version control system in which it is stored, or to + provide a link to the group policy it follows. + /p /sect /chapt should implies that every Debian package should have such file, but I don't think the vast majority of Debian packages need such a thing. Many have no special requirements beyond common best practices, and even the ones with a VCS provide sufficient information in the Vcs-* fields for the most part. The largest objection we've gotten to README.source is the addition of boilerplate files to lots of packages, and in retrospect that was probably a mistake (although format 3.0 mostly makes this go away again). I don't really want to add something else similar. I'd rather err on the side of telling maintainers not to bother unless there's something particularly important to say. For what it is worth, I agree with this assessment. There ought to be a place where a maintainer might, if they so desire, add more information on how development of the source package is done, and the policies that the maintainer follows, but policy should not put pressure on any maintainer that does not wish to do so to add a README.source. In other words, this information should be an opt-in entity, since it is not required for integration of the package into the OS, and not having the information will have only a minimal impact on most users. p + Instruction on how to use and manage a Debian source package + can be written in a filedebian/README.source/file + documentation file. + /p IMO, this is too vague, I'd like to see VCS mentioned as a concept, otherwise the reader will likely miss the point of this change. Also, use seems a bit odd to me. Hopefully all Debian source packages are used in exactly the same way: by building binary packages from them. :) I think the intention is more specifically to document anything unusual about maintaining the package that others need to be aware of. As I have been only superficially been following this, I am uncertain about what _kinds_ of documentation we are talking about here. The layout and policies are covered by the change above, so what else would this change be referring to? manoj -- Eeny, Meeny, Jelly Beanie, the spirits are about to speak! Bullwinkle Moose Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
On Sun, Nov 22 2009, Steve Langasek wrote: On Fri, Nov 20, 2009 at 12:33:50PM -0600, Manoj Srivastava wrote: Hi folks, The report #556972 was filed about a FHS violation in mounting selinuxfs on /selinux, which is accurate. Additionally, /sys does not appear in the FHS either, and is thus in a similar situation. Now, I can move the mount point in libselinux1, perhals to /lib/sellinux, but that would make us incompatible with other installations, and cause a large number of needless conflict with currently installed SELinux. Here is the backgound: Wouldn't it make more sense to expose this as a subdirectory of /sys rather than /lib, since this appears to be a kernel interface? Why didn't SELinux upstream engage with the FHS, to standardize on something consistent with the FHS's overall design and guard against such migration concerns in the first place? I have no comment on why the FHS is so dead or on the (lack of) motivation of upstream to do things one way or the other. 2) sysvinit (and upstart, if the patch is accepted) load the security policy for machines where SELinux is enabled, and need to mount selinuxfs to get details of the state of selinux in the kernel. Since /proc is not around when this happens, this is the one place where the distribution default od the selinuxfs mount point is hard coded. So the one place which hard-codes the mount point is init; but only sysvinit has this patch, and we have an upcoming transition away from sysvinit to upstart. There is a patch available in Debian BTS for upstart as well. And this lack of security features in upstart might be a cause for concern about migrating away from sysvinit; has this actually been addressed in a discussion about the proposed transition? Were the SELinux folks asked? And my understanding is that upstart upstream disagrees with the principle of hard-coding a particular LSM into init when an initramfs works just as well - and within the initramfs, things can mount selinuxfs anywhere they choose, if they unmount again later. Upstream apparently only support instalaltions with official kernels and mandate a initramfs, whichis something the Debian project has not yet required. Has upstart upstream investigated and addressed security concerns of the non-bypassability of a security policy if an initramfs is the only thing loading the security policy ? That doesn't sound to me like a major obstacle for a transition in any case, then? I personally think it is. Tacking on these requirements of an initramfs is something that has not been adequately discussed. 3) The default for fedora, gentoo, and Debian has been /selinux Where does Red Hat place theirs? /selinux. manoj -- Spirtle, n.: The fine stream from a grapefruit that always lands right in your eye. Sniglets, Rich Hall Friends Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 1/1] Use the Half-Configured state instead of the synonymous Failed-Config
Hi, I have now reworked this patch to use Half-Configured manoj --- These terms are synonyms. dpkg and dselect use halfconfigured internally and used to use Failed-config when talking to the user in soe cases. This patch ensures that policy uses the same term as dpkg does when talking to the user (Half-Configured) for consistency. Also, made the spelling of internal states consistent: Half-Configured, not: Half Configured, half configured, or half-configured. Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/policy.sgml b/policy.sgml index 042e82f..9c4bc5b 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3715,7 +3715,7 @@ Files: /example If this works, then the old-version is Installed, if not, the old version is in a - Failed-Config state. + Half-Configured state. /item /enumlist /item @@ -3823,7 +3823,7 @@ Files: If this fails, the package is left in a Half-Installed state, which requires a reinstall. If it works, the packages is left in - a Config Files state. + a Config-Files state. /item item Otherwise (i.e., the package was completely purged): @@ -3835,7 +3835,7 @@ Files: varnew-postrm/var abort-install /example If the error-unwind fails, the package is in a - Half Installed phase, and requires a + Half-Installed phase, and requires a reinstall. If the error unwind works, the package is in a not installed state. /item @@ -3916,13 +3916,13 @@ Files: varold-preinst/var abort-upgrade varnew-version/var /example If this fails, the old version is left in a - Half Installed state. If it works, dpkg now + Half-Installed state. If it works, dpkg now calls: example compact=compact varnew-postrm/var abort-upgrade varold-version/var /example If this fails, the old version is left in a - Half Installed state. If it works, dpkg now + Half-Installed state. If it works, dpkg now calls: example compact=compact varold-postinst/var abort-upgrade varnew-version/var @@ -4081,7 +4081,7 @@ Files: /example /p p -If this fails, the package is in a Failed-Config +If this fails, the package is in a Half-Configured state, or else it remains Installed. /p /item @@ -4417,12 +4417,12 @@ Build-Depends: foo [!i386] | bar [!amd64] be emunpacked/em the pre-dependency can be satisfied if the depended-on package is either fully configured, emor even if/em the depended-on - package(s) are only unpacked or half-configured, - provided that they have been configured correctly at - some point in the past (and not removed or partially - removed since). In this case, both the + package(s) are only unpacked or in the Half-Configured + state, provided that they have been configured + correctly at some point in the past (and not removed + or partially removed since). In this case, both the previously-configured and currently unpacked or - half-configured versions must satisfy any version + Half-Configured versions must satisfy any version clause in the ttPre-Depends/tt field. /p @@ -4479,7 +4479,7 @@ Build-Depends: foo [!i386] | bar [!amd64] p A package will not be regarded as causing breakage merely because its configuration files are still installed; it must - be at least half-installed. + be at least Half-Installed. /p p @@ -4533,7 +4533,7 @@ Build-Depends: foo [!i386] | bar [!amd64] p A package will not cause a conflict merely because its configuration files are still installed; it must be at least - half-installed. + Half-Installed. /p p -- 1.6.5.3 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
On Sat, Nov 21 2009, Kees Cook wrote: Hi, On Fri, Nov 20, 2009 at 12:33:50PM -0600, Manoj Srivastava wrote: The report #556972 was filed about a FHS violation in mounting selinuxfs on /selinux, which is accurate. Additionally, /sys does not appear in the FHS either, and is thus in a similar situation. Now, I can move the mount point in libselinux1, perhals to /lib/sellinux, but that would make us incompatible with other installations, and cause a large number of needless conflict with currently installed SELinux. Here is the backgound: Do the userspace tools use /selinux unconditionally or do they examine /proc/mounts? I'm not familiar with that portion of SELinux. Most userspace tools use libselinux to look at things in selinuxfs, and there is only on place where /selinux is hardcoded (and only as a fallback if /proc/mounts is not available or does not know about selinuxfs). Everything else will examine /proc/mounts. manoj -- Join the army, see the world, meet interesting, exciting people, and kill them. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
Hi folks, The report #556972 was filed about a FHS violation in mounting selinuxfs on /selinux, which is accurate. Additionally, /sys does not appear in the FHS either, and is thus in a similar situation. Now, I can move the mount point in libselinux1, perhals to /lib/sellinux, but that would make us incompatible with other installations, and cause a large number of needless conflict with currently installed SELinux. Here is the backgound: 1) There are a lot of instances of programs looking things up in selinuxfs (indirectly through libselinux). Most of these instances look through /proc/mounts to discover where selinuxfs is mounted, and thus do not care about the actual location 2) sysvinit (and upstart, if the patch is accepted) load the security policy for machines where SELinux is enabled, and need to mount selinuxfs to get details of the state of selinux in the kernel. Since /proc is not around when this happens, this is the one place where the distribution default od the selinuxfs mount point is hard coded. 3) The default for fedora, gentoo, and Debian has been /selinux 4) Lots of people have also setup /etc/fstab to mount selinuxfs on /selinux 5) there are user scripts that assume they can look into /selinux on SELinux enabled machines, and this is a lot of things to change This patch explicitly allows /sys and /selinux as additional directories int he root file system allowed under the policy. Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 34a45d5..b8b97f4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5638,6 +5638,15 @@ libbar 1 bar1 (= 1.0-1) symlinked there, is relaxed to a recommendation. /p /item + item +p + The following directories in the root filesystem are + additionally allowed: file/sys/file and + file/selinux/file. footnoteThese directories + are used as mount points to mount virtual filesystems + to get access to kernel information./footnote +/p + /item /enumlist /p -- 1.6.5.3 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555009: debian-policy: alt. changelog formats are still advertised
Hi, The appendices are not normative parts of policy, they are around so that we do not lose bits of documentation that ought to be part of dpkg documentation. Having said that, perhaps it is time to yank these non-normative sections into a separate document, and away from policy proper? manoj -- Money is the root of all money. the moving finger Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 1/1] Use the Failed-Config state instead of the synonymous halfconfigured
These terms are synonyms. dpkg and dselect use halfconfigured internally and Failed-config when talking to the user. This patch ensures that policy uses the same term as dpkg does when talking to the user (Failed-Config) for consistency. Now looking for seconds on this wording. Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/policy.sgml b/policy.sgml index 042e82f..8bfd563 100644 --- a/policy.sgml +++ b/policy.sgml @@ -4417,12 +4417,12 @@ Build-Depends: foo [!i386] | bar [!amd64] be emunpacked/em the pre-dependency can be satisfied if the depended-on package is either fully configured, emor even if/em the depended-on - package(s) are only unpacked or half-configured, - provided that they have been configured correctly at - some point in the past (and not removed or partially - removed since). In this case, both the + package(s) are only unpacked or in the Failed-Config + state, provided that they have been configured + correctly at some point in the past (and not removed + or partially removed since). In this case, both the previously-configured and currently unpacked or - half-configured versions must satisfy any version + Failed-Config versions must satisfy any version clause in the ttPre-Depends/tt field. /p -- 1.6.5.3 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 1/1] New virtual package: cron-daemon
Create a virtual cron daemon package that:
- Has to provide /usr/bin/crontab and support crontab entries
- Correct execution of /etc/cron.d
- Correct support of /etc/crontab
- Support of crontab entries with names for days and months,
ranges, step values
- Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
Signed-off-by: Javier Fernández-Sanguino Peña j...@computer.org
Signed-off-by: Manoj Srivastava sriva...@debian.org
---
policy.sgml| 39 +--
virtual-package-names-list.txt |4
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 042e82f..76ac0d4 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -6552,13 +6552,48 @@ Reloading vardescription/var configuration...done.
prgnanacron/prgn. Thus, you should only use this
directory for jobs which may be skipped if the system is not
running.)/p
+ p
+ Unlike filecrontab/file files described in the IEEE Std
+ 1003.1-2008 (POSIX.1) available from
+ url id=http://www.opengroup.org/onlinepubs/9699919799/;
+ name=The Open Group, the files in
+ file/etc/cron.d/file and the file
+ file/etc/crontab/file have seven fields; namely:
+ enumlist
+itemMinute [0,59]/item
+itemHour [0,23]/item
+itemDay of the month [1,31]/item
+itemMonth of the year [1,12]/item
+itemDay of the week ([0,6] with 0=Sunday)/item
+itemUsername/item
+itemCommand to be run/item
+ /enumlist
+ Ranges of numbers are allowed. Ranges are two numbers
+ separated with a hyphen. The specified range is inclusive.
+ Lists are allowed. A list is a set of numbers (or ranges)
+ separated by commas. Step values can be used in conjunction
+ with ranges.
+/p
p
- The scripts or crontab entries in these directories should
+ The scripts or ttcrontab/tt entries in these directories should
check if all necessary programs are installed before they
try to execute them. Otherwise, problems will arise when a
package was removed but not purged since configuration files
- are kept on the system in this situation./p
+ are kept on the system in this situation.
+/p
+
+p
+ Any ttcron/tt daemon must provide
+ file/usr/bin/crontab/file and support normal
+ ttcrontab/tt entries as specified in POSIX. The daemon
+ must also support names for days and months, ranges, and
+ step values. It has to support file/etc/crontab/file,
+ and correctly execute the scripts in
+ file/etc/cron.d/file. The daemon must also correctly
+ execute scripts in
+ file/etc/cron.{hourly,daily,weekly,monthly}/file.
+/p
/sect
sect id=menus
diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
index d1beab8..9ba66e5 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -83,6 +83,7 @@ System
other applications
time-daemon anything that serves as a time daemon
ups-monitor anything that is capable of controlling an UPS
+ cron-daemon Any cron daemon that correctly follows policy
requirements
Documentation
-
@@ -315,3 +316,6 @@ Russ Allbery:
Rename inetd-superserver to inet-superserver
2 Dec 2007 Added ttf-japanese-gothic
Added ttf-japanese-mincho
+
+Manoj Srivastava:
+ 21 Nov 2009 (Re)Added cron-daemon
--
1.6.5.3
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556015: debian-policy: Clarify requirements for copyright file
the requirements for using a symlink instead of a + directory as file/usr/share/doc/varpackage/var/file + described in ref id=addl-docs must be met. This means + both packages must come from the same source package and the + package must depend on the package containing its copyright + and distribution license. + /item + + item + There must be a direct dependency on the package containing + the copyright and distribution license. An indirect + dependency via a third package is not sufficient. + /item + + item + The file/usr/share/doc/varpackage/var/copyright/file + file contained in the other package must contain the + copyright and distribution license for both packages. + /item + + item + The copyright file contained in the other package must meet + all of the requirements listed below. + /item + /enumlist /p p - In addition, the copyright file must say where the upstream - sources (if any) were obtained. It should name the original - authors of the package and the Debian maintainer(s) who were - involved with its creation. + The copyright file must neither be compressed nor be a symbolic + link. /p p - Packages in the emcontrib/em or emnon-free/em archive - areas should state in the copyright file that the package is not - part of the Debian GNU/Linux distribution and briefly explain - why. + In addition to the copyright and distribution license, the + copyright file must say where the upstream sources (if any) were + obtained. Packages in the emcontrib/em or emnon-free/em + archive areas should state in the copyright file that the + package is not part of the Debian GNU/Linux distribution and + briefly explain why. /p p A copy of the file which will be installed in file/usr/share/doc/varpackage/var/copyright/file should - be in filedebian/copyright/file in the source package. - /p - - p - file/usr/share/doc/varpackage/var/file may be a symbolic - link to another directory in file/usr/share/doc/file only if - the two packages both come from the same source and the - first package Depends on the second. These rules are - important because copyrights must be extractable by - mechanical means. + normally be in filedebian/copyright/file in the + corresponding source package. If a source package produces + binary packages with separate copyright files (if, for instance, + different binary packages produced from one source package have + substantially different distribution licenses), it may include + multiple copyright files for installation into the different + binary packages, but filedebian/copyright/file in the source + package must still contain the copyright and distribution + license for the entirety of the source package. /p p @@ -9120,10 +9166,12 @@ END-INFO-DIR-ENTRY /p p - You should not use the copyright file as a general fileREADME/file - file. If your package has such a file it should be - installed in file/usr/share/doc/varpackage/var/README/file or - fileREADME.Debian/file or some other appropriate place./p + You should not use the copyright file as a general + fileREADME/file file. If your package has such a file it + should be installed in + file/usr/share/doc/varpackage/var/README/file or + fileREADME.Debian/file or some other appropriate place. + /p /sect sect -- QOTD: Talent does what it can, genius what it must. I do what I get paid to do. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpKl37bEBq8N.pgp Description: PGP signature
Re: Difficulty rebuilding text files with org-mode
On Thu, Nov 12 2009, Russ Allbery wrote: Manoj, when I tried to rebuild upgrading-checklist, I got the following error: % /usr/bin/emacs23 --batch -Q -l ./README-css.el -l org --visit upgrading-checklist.org --funcall org-export-as-ascii Loading vc-git... Autoloading failed to define function org-export-as-ascii Hmm. I can't reproduce this when running as me. I'll see what I get in my build virtual machine this weekend. Running: % /usr/bin/emacs23 --batch -Q -l ./README-css.el -l org -l org-ascii --visit upgrading-checklist.org --funcall org-export-as-ascii Loading vc-git... Saving file /home/eagle/dvl/debian/policy/upgrading-checklist.txt... Wrote /home/eagle/dvl/debian/policy/upgrading-checklist.txt ASCII export done, pushed to kill ring and clipboard instead worked. I'm not sure what's going on, since org-install.el does have an autoload for org-export-as-ascii. HTML generation worked fine. Well, if it works, I have no problem explicitly loading org-ascii. On an unrelated note, since there have been no objections to my modeling exercise about maintainer script call graph as it relates to package state transitions, I am planning on adding it to the policy package. Should I install this informative document in a new docs subdirectory? manoj -- Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. Albert Einstein : Understanding the world Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#552690: mknod-in-maintainer-script postinst:39
On Thu, Nov 12 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: On Thu, Oct 29 2009, Simon Horman wrote: Could you suggest a policy-compliant method of creating fifos for the package? At the time that I added mknod to the maintainer script the consensus that this was the best option available. You may use mkfifo instead of mknod, since there is no policy prohibition on mkfifo (and it can't be used to make special files). Perhaps we can add a footnote to policy mentioning mkfifo where the mknod prohibition is written? Policy currently isn't explicit about named pipes unless one considers them to be device files (which they sort of are and sort of aren't). I propose the following change to clarify this. I'm looking for seconds. commit 23cf3d94a253f1142fcd97d39320419b1014448d Author: Russ Allbery r...@debian.org Date: Thu Nov 12 13:26:50 2009 -0800 Clarify policy on named pipes in packages Make explicit the requirement that packages not include named pipes in addition to device files. State that named pipes must be created in postinst and removed in prerm or postrm as appropriate. Suggest in a footnote using mkfifo rather than mknod to avoid false positives from package checkers. diff --git a/policy.sgml b/policy.sgml index 9fcb660..34a45d5 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7256,8 +7256,8 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq headingDevice files/heading p - Packages must not include device files in the package file - tree. + Packages must not include device files or named pipes in the + package file tree. /p p @@ -7282,6 +7282,18 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq file/dev/cu*/file devices should be changed to use file/dev/ttyS*/file. /p + + p + Named pipes needed by the package must be created in + the prgnpostinst/prgn scriptfootnote + It's better to use prgnmkfifo/prgn rather + than prgnmknod/prgn to create named pipes so that + automated checks for packages incorrectly creating device + files with prgnmknod/prgn won't have false positives. + /footnote and removed in + the prgnprerm/prgn or prgnpostrm/prgn script as + appropriate. + /p /sect sect id=config-files Seconded. manoj -- You can't cheat the phone company. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpTeHQNpslW9.pgp Description: PGP signature
Bug#553576: Policy should not encourage violation of the FHS
Package: debian-policy Version: 3.8.3.0 Severity: important Hi, Debian packages should not install files under /var/www. This is not one of the /var directories in the File Hierarchy Standard and is under the control of the local administrator. Packages should not assume that it is the document root for a web server; it is very common for users to change the default document root and packages should not assume that users will keep any particular setting. Packages that want to make files available via an installed web server should instead put instructions for the local administrator in a README.Debian file and ideally include configuration fragments for common web servers such as Apache. As an exception, packages are permitted to create the /var/www directory due to its past history as the default document root, but should at most copy over a default file in postinst for a new install. Refer to Filesystem Hierarchy Standard (The /var Hierarchy) for details. But then, we turn around in section 11.5.4, and say: , | Web Applications should try to avoid storing files in the Web | Document Root. Instead they should use the /usr/share/doc/package | directory for documents and register the Web Application via the | doc-base package. ` So far, so good. , | If access to the web document root is unavoidable then use /var/www | as the Document Root. ` Whoa. What makes for the situation to be unvoidable? Why should this ever be needed? What if the (optinal) /var/www is not the document root, and is not a symlink to the document root? I think we should rethink the unavoidable circumstances. manoj -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.4-anzu-2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.5 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#553420: debian-policy: Please clarify what is the interface for building binary packages.
package debian-policy user debian-pol...@packages.debian.org severity 553420 wishlist usertag 553420 = normative issue thanks On Fri, Oct 30 2009, Charles Plessy wrote: there is currently a discussion on debian-de...@lists.debian.org with a strong disagreement on what the Policy specifies for building binary packages, and what it should specify. I fail to see a strong disagreement, but that is perhaps just me. http://lists.debian.org/msgid-search/4ae85d08.1050...@e-tobi.net (I can prepare a summary if there is interest for this). In a first step, I think that it would be very helpful to clarify what is the build interface as of Policy 3.8.3. Currently the Policy specifies what the debian/rules file is, gives a special role to dpkg-buildpackage, and the build interface is extrapolated with conflicting interpretation among the developers. The clarification has already been offered, and has one second: --8---cut here---start-8--- --- policy.sgml 2009-10-21 20:49:37 + +++ policy.sgml 2009-10-31 01:10:42 + @@ -1725,7 +1725,10 @@ p It must start with the line tt#!/usr/bin/make -f/tt, so that it can be invoked by saying its name rather than - invoking prgnmake/prgn explicitly. + invoking prgnmake/prgn explicitly. That is, invoking + either of ttmake -f debian/rules emargs.../em/tt + or tt./debian/rules emargs.../em/tt must cause + identical behaviour in each case. /p p --8---cut here---end---8--- Rationale: Since debian/rules must be a makefile, and policy has already specified that the interpreter the fle should be called with s make (it even specifies that the #! line), it follows that how the file is invoked should not change the behaviour of the build system. The clarifying language above was proposed by Ben Finney, and has been seconded by Manoj Srivastava. manoj -- I can't complain, but sometimes I still do. Joe Walsh Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26 2009, Bastian Blank wrote: On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: I created a elaborate test case tos ee if we are in a chroot, if not if /proc/1 is actually /sbin/init, and that telinit exists (example below). Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Even if the security system has changed? I dont't think so (better safe than sorry). Especially if the changes impact the ability to load the security policy in the first place. Just take it that there may be cases where it is better to abort the install rather than not re-exec init. Does this need discussion? Yes, it is highly sysvinit and Linux specific. The solution was. But this is not a generic solution in the first place. What we have is a potential issue, which was solved in a particular manner for specific packages. If this issue has broader impact, a more generic solution will be needed. Whic brings us to the raison d'etre for this thread. manoj -- Two sure ways to tell a REALLY sexy man; the first is, he has a bad memory. I forget the second. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26 2009, Bastian Blank wrote: On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Even if the security system has changed? I dont't think so (better safe than sorry). Which security system? Is there a list of packages trying to reexec init? The listed bugs only show libsepol and libselinux, both do nothing in respect of that. So far, I hav not needed to. But I can see where there is a major change in libselinux (we are at the same soname so far, so this has not happened), and the new libselinux is needed to not have people bypass init.d's security setup by exploiting a bug in the old system (perhaps a change is needed in libselinux/libsepol to even load new policy). If that happens, not being able to re-exec init can be grounds for a failure to boot (as it is now if you enable selinux and init can't load policy). Selinux can only be activated on boot anyway. What does this have to do with the price of rice in china? The scenario of interest is a system with selinux enabled and in enforcing, and a upgrade of security libraries (and policy, perhaps). manoj -- There are more old drunkards than old doctors. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26 2009, Bastian Blank wrote: Policy is not coupled with init or the libs. This is a problem between the kernel and the policy tools. This is not totally true: init loads the initial policy, and that means that linking with new versions of selinux libs makes a difference at startup. It is, however, irrelevant for upgrades -- unless changes in the future libsepol and/or libselinux and init expand init's role in security. Which is why currently, as I have said before, re-execing init is opportunistic. This may or may not be the case in the future. Am I not getting through, somehow? Have I not re-iterated that the current situation does not absolutely require init to be re-exec'd, but it is not unfathomable that it might be in the future? And that potential is why I brought it up in the first place? Anyway, I am done addressing this red herring, shiny thought it be. manoj -- [Crash programs] fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. -- Wernher von Braun Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545691: diverting telinit
Hi, I am pulling this discussion off 545...@bugs.debian.org and on to the devel list, in case it has broader interest. The issue was that a maintainer script called telinit to communicate with init, and that does not work when the kernel has been started with 'init=/bin/bash'. (qemubuilder was impacted in the bug, but this might need a general fix). I created a elaborate test case tos ee if we are in a chroot, if not if /proc/1 is actually /sbin/init, and that telinit exists (example below). Does this need discussion? manoj if [ -x /sbin/init ] [ -d /proc/1 ] [ $(stat -c %d/%i /sbin/init) = $(stat -Lc %d/%i /proc/1/exe 2/dev/null) ] ; then # So, init exists, and there is a linuxy /proc, and the inode of # the executable of the process with uid 1 is the same as # /sbin/init (ok, no init=/bin/sh going on) if [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root 2/dev/null) ]; then # the devicenumber/inode pair of / is the same as that of # /sbin/init's root, so we're *not* in a chroot # Final sanity check. Make sure there is a /dev/initctl # for us to talk to if [ -e /dev/initctl ]; then # Use telinit if available, it is better form, according # to the sysvinit maintainer. if [ -x /sbin/telinit ]; then (telinit u ; sleep 1) else (init u ; sleep 1) fi fi fi fi -- Whether in the village or the forest, whether on high ground or low, wherever the enlightened live, that is a delightful spot. 98 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Fri, Oct 23 2009, brian m. carlson wrote: On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: if [ -x /sbin/init ] [ -d /proc/1 ] [ $(stat -c %d/%i /sbin/init) = $(stat -Lc %d/%i /proc/1/exe 2/dev/null) ] ; then # So, init exists, and there is a linuxy /proc, and the inode of # the executable of the process with uid 1 is the same as # /sbin/init (ok, no init=/bin/sh going on) if [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root 2/dev/null) ]; then # the devicenumber/inode pair of / is the same as that of # /sbin/init's root, so we're *not* in a chroot # Final sanity check. Make sure there is a /dev/initctl # for us to talk to if [ -e /dev/initctl ]; then Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I think it's something like /etc/.initctl. They do, however, have a linuxy proc. You should probably check with the porters as to what location is appropriate on those architectures. Well, this was not an issue i my case, since these packages do not support ! linux, but yes, a generic solution would have to cater to that as well. manoj -- Today is the first day of the rest of the mess. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: minor edits
Hi, Thanks for the report. I have applied fixes to all of the bugs pointed out, apart from the LinuxThreads/NPTL issue, which I think is not a typo, but a real normative bug. I think that LinuxThreads are mostly obsolete, and I think there is a bug report for the reference to be removed from policy. I have pushed out the changes to the public git repo as well. manoj -- MAC user's dynamic debugging list evaluator? Never heard of that. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Informative addendum to policy clarifying dpkg/maintainer script interface
On Wed, Oct 21 2009, Frank Küster wrote: Manoj Srivastava sriva...@debian.org wrote: Hi, I have created a document to clarify the interaction between maintainer scripts and dpkg, and examines the state changes for a package when a user interacts with the packaging system. Thank you, that looks very useful. What I'm missing, however, is any reference to debconf's config script. Isn't that called by dpkg, too? Hmm. There are three different ways the config script is called, one is (for apt version 0.5 or above) via /etc/apt/apt.conf.d/70debconf -- this calls dpkg-preconfigure (8) to do to preconfigure the packages it is trying to install. That is beyond the scope of the document, since it is just an external program (apt) calling dpkg-preconfigure; and no package state change happens here -- this is just a debconf db update thing. The second way is when you initiate debconf/confmodule in your postinst, then debconf tries to call the config script again; this activity is thus part of what the postinst does, and not something this document covers (since we do not say anything about what maintainer scripts do or not do, just how they are called and what they return). Thirdly, if you call dpkg-reconfigure, the config script is run, but, again, this document is not documenting dpkg-reconfigure (or dpkg-preconfigure). As far asI can see, dpkg-preconfigure also doe snot cause a package state transition, it just runs the scripts (prerm. config, postinst). Could the dpkg folks chine in if I am wrong? manoj -- Bugs, pl. n.: Small living things that small living boys throw on small living girls. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Informative addendum to policy clarifying dpkg/maintainer script interface
Hi, I have created a document to clarify the interaction between maintainer scripts and dpkg, and examines the state changes for a package when a user interacts with the packaging system. The dynamic interactions between the packaging system and the package's maintainer scripts are described formally using UML diagrams. This document does not attempt to describe what the maintainer scripts can or can not do, concentrating instead mostly one the packaging system interface. It also provides a call graph of the maintainer scripts. This document is meant to be informative, not normative, at this point, and is presented here mostly since the maintainer scripts interaction section of policy is one of the more opaque segments. However, it also is trying to formally define the packaging system interface formally, and is meant to become normative at some point in the future, once it has buy in from the interested parties and has been checked for correctness. An early draft was sent over to the debian policy mailing list, but I thought the time has come to widen the audience a bit. Any feedback is appreciated. Please follow up to the policy list (debian-policy@lists.debian.org mailing.) Especially welcome would be any feedback from the dpkg folk about correctness of the interactions depicted. Oh, and before I forget, this is where the document lives currently: http://people.debian.org/~srivasta/MaintainerScripts.html Thanks in advance, manoj -- Today is a good day to bribe a high-ranking public official. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Informative addendum to policy clarifying dpkg/maintainer script interface
On Mon, Oct 19 2009, Patrick Matthäi wrote: Manoj Srivastava schrieb: Hi, I have created a document to clarify the interaction between maintainer scripts and dpkg, and examines the state changes for a package when a user interacts with the packaging system. The dynamic interactions between the packaging system and the package's maintainer scripts are described formally using UML diagrams. This document does not attempt to describe what the maintainer scripts can or can not do, concentrating instead mostly one the packaging system interface. It also provides a call graph of the maintainer scripts. This document is meant to be informative, not normative, at this point, and is presented here mostly since the maintainer scripts interaction section of policy is one of the more opaque segments. However, it also is trying to formally define the packaging system interface formally, and is meant to become normative at some point in the future, once it has buy in from the interested parties and has been checked for correctness. An early draft was sent over to the debian policy mailing list, but I thought the time has come to widen the audience a bit. Any feedback is appreciated. Please follow up to the policy list (debian-policy@lists.debian.org mailing.) Especially welcome would be any feedback from the dpkg folk about correctness of the interactions depicted. Oh, and before I forget, this is where the document lives currently: http://people.debian.org/~srivasta/MaintainerScripts.html Thanks in advance, manoj Nice work, but I think it would be a good idea to declare every parameter from dpkg to the maintainer script. Could you elaborate as to where you want to see these parameters? Isn't this already covered fairly cleanly in policy? I tend to find §6.5 (Summary of ways maintainer scripts are called) fairly straightforward, §6.6, 6.7, and 6.8 are the ones I find akin to a maze of twisty little passages, all alike. manoj -- A 'full' life in my experience is usually full only of other people's demands. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Maintainer script informative call graph
Hi, Inspired by Marga's excellent document claryfying the maintainer scripts at http://women.debian.org/wiki/English/MaintainerScripts, and also enthused about Emacs org-mode's ability to create a simple plain ascii input file and leveragte things like graphviz and ditaa, I have some up with a slightly different take on clarification of the maintainer script call sequence. Please have a look-see at: http://people.debian.org/~srivasta/MaintainerScripts.html I'm attaching the source below. I think I am going to continue to enhance it, but I ran out of steam tonight. I am proposing adding this to the policy package, once it gets polished a bit more, and checked for correctness. manoj #+STARTUP: hidestars showall #+TITLE: Maintainer scripts #+AUTHOR:Manoj Srivastava #+EMAIL: sriva...@debian.org #+DATE: 2009-10-16 Fri #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:info toc:1 path:org-info.js tdepth:2 ftoc:t #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ * Introduction This document is meant to clarify the interaction between maintainer scripts and the state changes for a package when a user interacts with the packaging system. This was inspired by Margarita Manterola's [[http://women.debian.org/wiki/English/MaintainerScripts][excellent treatise]] on the subject, but has a slightly different slant: this document is more concerned about user actions, and the resulting state transitions of a package's state on a Debian installation, rather than a maintainer script centric treatment of the process. * Common Use Cases To start with, we consider the most common use cases related to a user's interaction with the packaging system: - *Install*: Starting with a package which is not installed on the system, the user asks the packaging system to install a package. If all goes well, the end result is that the package is installed on the system. - *Remove*: Starting with a package that is currently installed on the system, the user asks the packaging system to remove it. If all goes well, only configuration files shall remain on the system at the end. - *Purge*: Starting with the state when only configuration files remain on the system, the user asks the package system to remove even the configuration files. If all goes well, the package will be fully un-installed. - Starting with a package installed on the system, the user asks the system to fully uninstall the package. This is not an independent use case, it is just the /Remove/ followed by a /Purge/, and we do not consider it separately below. - *Reinstall*: Starting with just the configuration files remaining on the system, the user asks the packaging system to install the package again (potentially newer version of the package). - *Upgrade*: Starting with a version of the package installed on the system, the user asks the packaging system to install a newer version of the package. (A variation is the case where the old and the new version of the package are the same, but it follows the same process). This is not as complex a scenario as one might be afraid of; there are only three states a package may be in when the user initiates the action (/Not Installed/, /Configuration files only/, and /Installed/). These states are also successful terminal state, and there are only three failure terminal states (/Half Installed/, /Failed config/, and /Unpacked/). In the treatment below, we do not discuss details of failure modes, we just detail what happens when a maintainer script encounters an error. Also, we do not go into early sanity checks, for example, complications like the absence of a dependency when trying to (re)install a package, or the presence of a conflicting package. We also do not deal with the cases where the package we are trying to remove has other installed packages that depend on it; in all these cases the result is to abort the operation early, and let the user handle further action. ** Install a previously unknown package This is the case where a package is not currently installed on the system, and the user asks the packaging system to install version /V1/. *** State diagram #+begin_ditaa InstallState.png -r -o -s 0.8 ++ | +--+ | | | | | | | v | | /---*--*+ /--+ | | | Not Installed | | Half Installed | | | | cGRE** cRED
Re: Maintainer script informative call graph
On Fri, Oct 16 2009, Raphael Hertzog wrote: On Fri, 16 Oct 2009, Manoj Srivastava wrote: Please have a look-see at: http://people.debian.org/~srivasta/MaintainerScripts.html I'm attaching the source below. I think I am going to continue to enhance it, but I ran out of steam tonight. I am proposing adding this to the policy package, once it gets polished a bit more, and checked for correctness. It would be nice if it could be updated to take into account the trigger support. We have new states (triggers-awaited, triggers-pending) and new postinst argument for this. I have added that, as well as the deconfigure/removal of conflicting packages and their dependencies, though I think it is with a major impact on simplicity. However, of this is going to policy, there is something to be said about vying for completeness. I see why marga elected to elide these details. So, a new version is up at the above URL, please check for correctness. I think I have incorporated everything that is in policy in this document now. Incidentally, this reminds me that the trigger stuff is not documented in policy, and I think needs to be, can someone better acquainted with triggers take the lead in crafting the wording for policy? (I must confess I had to read code in order to get my head wrapped around awaiting and pending and the distinction between these two -- and the fact that I tend to link pulling a trigger with instantaneous activityy, like something going Ka-Pow). manoj -- Krogt, n. (chemical symbol: Kr): The metallic silver coating found on fast-food game cards. Rich Hall, Sniglets Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file
On Sun, Oct 11 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: But someone really should be writing this up, since the bug report was, in my opinion, on point: this stuff needs to be written up, and I think that the wiki stuff is already not as good as the README is when it comes to git process (far too many needless merges in that process). If someone is willing to write this up and maintain it in debiandoc, great. Or else perhaps one could reconsider my offer to maintain it in the current form. I'm fine to maintain it in org-mode. I haven't played with it yet, but I'm sure it can't be that hard, and it's not like the details change all that much. Right. Given that we do have a bug asking for this documentation, and that this is already written, and no one else has stepped up to re-write it in another format, I think I shall merge this branch in, at least as an interim measure. Given that this is not really policy, but packaging, we can always decide to change our mind. I think we're likely to move to Docbook in the long run, and when we do that, we can look at rewriting it, but until then, I'm happy to use whatever format whoever did the original work thinks is easiest to maintain. I probably would have used POD. :) Well, org-mode has a docbook output filter, so we can have a head start once we do convert. But I contend that org-mode markup is waaay easier to write than docbook xml (involves less typing), and is far more readable in raw format than XML is. I did think about pod, but org-mode is far more powerful than pod is, and supports all kinds of things (built-in plain text spreadsheet, footnote support, various modes of URL, image support, etc -- all supported for various output formats). Also, I confess I am really really into org-mode, what with sing it in Ikiwiki and for my GTD agendas. manoj -- Dare to be naive. Buckminster Fuller Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: [14a9406] Fix for Bug#545548 committed to git
tags 545548 +pending thanks Hi, The following change has been committed for this bug by Manoj Srivastava sriva...@debian.org on Tue, 13 Oct 2009 12:05:18 -0500. The fix will be in the next upload. = [master]: Added changelog for bug 545548 This patch add a README file, rendered as txt and html, and also documents the policy change process, again rendered as text and HTML. While the text and HTML files are automatically generated, they are shipped in the package itself so as to avoud depending on a recent version of Emacs during build. If a new Emacs is present, the .txt and .html files shall be regenerated if the org file is newer. The contents of the new documents are based on (but no identical to) the contents of related pages on the Debian wiki. The long term plan is to make these documents the canonical ones, and have the Wiki point to these pages. Also render out a upgrading-checklist.txt (we can also do a docbook version later) Closes: #545548 Signed-off-by: Manoj Srivastava sriva...@debian.org = -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#391836: debian-policy: New virtual package: cron-daemon
On Sun, Oct 11 2009, Russ Allbery wrote:
Requirements:
1) Be able to run a batch job periodically, as defined in the POSIX
standards document.
2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}, as
long as the files are conforming to POSIX standards.
Russ, do you still want policy changed, given that the requirements are
so pared down now?
I just want to be sure that we write down the criteria that we came up
with in this thread somewhere so that people know when they can
provide the virtual package.
Separately, I'll note that Policy 9.5 strongly implies that
/etc/cron.d/file will work, using the same syntax as /etc/crontab
without specifying what that syntax is. If the Debian project is going to
support alternative cron daemons than the default, we really need to
document what that syntax is so that packages know what to expect and what
they can safely use.
I suggest, then, that we follow POSIX (please note that @reboot
and @daily and other such convenient contractions are not mentioned in
the standard, though cron(1) supports them):
http://www.opengroup.org/onlinepubs/009695399/utilities/crontab.html
The important bits are extracted below. Should policy add
support requirements for @reboot et al?
--8---cut here---start-8--- Upon
execution of a command from a crontab entry, the implementation shall
supply a default environment, defining at least the following
environment variables:
HOMEA pathname of the user's home directory.
LOGNAME The user's login name.
PATHA string representing a search path guaranteed to find all of
the standard utilities.
SHELL A pathname of the command interpreter. When crontab is invoked
as specified by this volume of IEEE Std 1003.1-2001, the value
shall be a pathname for sh.
The values of these variables when crontab is invoked as specified by
this volume of IEEE Std 1003.1-2001 shall not affect the default values
provided when the scheduled command is run.
If standard output and standard error are not redirected by commands
executed from the crontab entry, any generated output or errors shall be
mailed, via an implementation-defined method, to the user.
In the POSIX locale, the user or application shall ensure that a crontab
entry is a text file consisting of lines of six fields each. The fields
shall be separated by blanks. The first five fields shall be integer
patterns that specify the following:
1. Minute [0,59]
2. Hour [0,23]
3. Day of the month [1,31]
4. Month of the year [1,12]
5. Day of the week ([0,6] with 0=Sunday)
Each of these patterns can be either an asterisk (meaning all valid
values), an element, or a list of elements separated by commas. An
element shall be either a number or two numbers separated by a hyphen
(meaning an inclusive range). The specification of days can be made by
two fields (day of the month and day of the week). If month, day of
month, and day of week are all asterisks, every day shall be matched. If
either the month or day of month is specified as an element or list, but
the day of week is an asterisk, the month and day of month fields shall
specify the days that match. If both month and day of month are
specified as an asterisk, but day of week is an element or list, then
only the specified days of the week match. Finally, if either the month
or day of month is specified as an element or list, and the day of week
is also specified as an element or list, then any day matching either
the month and day of month, or the day of week, shall be matched.
The sixth field of a line in a crontab entry is a string that shall be
executed by sh at the specified times. A percent sign character in this
field shall be translated to a newline. Any character preceded by a
backslash (including the '%' ) shall cause that character to be treated
literally. Only the first line (up to a '%' or end-of-line) of the
command field shall be executed by the command interpreter. The other
lines shall be made available to the command as standard input.
Blank lines and those whose first non- blank is '#' shall be ignored.
--8---cut here---end---8---
Given that, should this be duplicated in a normative section of
policy? Or can we just vaguely hand wave the reader over to POSIX? Or
add this as an informative footnote?
manoj
--
Use what talents you possess: the woods would be very silent if no birds
sang there except those that sang best. -- Henry Van Dyke
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file
On Tue, Oct 13 2009, Bill Allombert wrote:
On Tue, Oct 13, 2009 at 10:23:29AM -0500, Manoj Srivastava wrote:
On Sun, Oct 11 2009, Russ Allbery wrote:
Manoj Srivastava sriva...@debian.org writes:
But someone really should be writing this up, since the bug
report was, in my opinion, on point: this stuff needs to be written up,
and I think that the wiki stuff is already not as good as the README is
when it comes to git process (far too many needless merges in that
process). If someone is willing to write this up and maintain it in
debiandoc, great. Or else perhaps one could reconsider my offer to
maintain it in the current form.
I'm fine to maintain it in org-mode. I haven't played with it yet,
but I'm sure it can't be that hard, and it's not like the details
change all that much.
Right. Given that we do have a bug asking for this
documentation, and that this is already written, and no one else has
stepped up to re-write it in another format, I think I shall merge this
branch in, at least as an interim measure. Given that this is not
really policy, but packaging, we can always decide to change our mind.
Well I will do that, but first, I like to be remembered why the old
policy-process document has been removed.
Well, because it had become obsolete at the time it was
removed. The old policy-process document was based on the work flow I
created, and Russ streamlined the work flow and created the new policy
process document, which is not obsolete (yet ;-).
I further changed some git related steps in the process, to
reduce unnecessary merges back and forth, and also to prevent loads of
obsolete branches piling up in the public repository (look at gitk
--all to see how recent changes are less confusing to follow), and that
is the Process.{org,txt,html} document now included in the policy
package.
manoj
--
Waste not, get your budget cut next year.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file
On Tue, Oct 13 2009, Bill Allombert wrote:
On Tue, Oct 13, 2009 at 01:15:04PM -0500, Manoj Srivastava wrote:
On Tue, Oct 13 2009, Bill Allombert wrote:
Well I will do that, but first, I like to be remembered why the old
policy-process document has been removed.
Well, because it had become obsolete at the time it was
removed. The old policy-process document was based on the work flow I
created, and Russ streamlined the work flow and created the new policy
process document, which is not obsolete (yet ;-).
I further changed some git related steps in the process, to
reduce unnecessary merges back and forth, and also to prevent loads of
obsolete branches piling up in the public repository (look at gitk
--all to see how recent changes are less confusing to follow), and that
is the Process.{org,txt,html} document now included in the policy
package.
How are we supposed to build the package from the git repository now ?
Building the package from the git repo should still work. As
long as the .org files are unmodified, the html files et al will still
be in sync. If you modify the .org files, you need to install emacs23,
and everything ought to work nominally.
If there are problems, please let me know, these would be bugs
that need fixing.
manoj
--
LILO, you've got me on my knees! -- David Black, dbl...@pilot.njin.net,
with apologies to Derek and the Dominos, and Werner Almsberger
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
On Wed, Oct 07 2009, Raphael Hertzog wrote: On Tue, 06 Oct 2009, Manoj Srivastava wrote: Do we really need to have policy to tell people not to create buggy packages? Well, there are people out there that don't know that doing such things are bugs. I would like to be able to ede them pointing to our policy, explaining that it's what makes of us a quality distribution. This by itself does not meet the criteria for inclusion in policy. There are all kinds of things that are bugs, and are not mentioned in policy; and adding them to policy is needless bloat. If you wish, a new document can be started somewhere, about common mistakes, and this can fit well in there. Policy is not, after all, a club to beat people on the head with. It is however a required reading for any new maintainer. Again, that is a reason to keep the policy document from bring bloated, and prevent mission creep. The size and density of the policy manuals are always an issue, and it seems to me that these are obvious bugs that are already covered by release manager requirements and bug reporting guidelines; adding Where ? Well, for the latter: http://www.debian.org/Bugs/Developer Since changes in interfaces will make unrelated software break, For the former, I think it would be a decent addition to a document like a) http://release.debian.org/lenny/rc_policy.txt or, failing that, the developers reference as a Good Practice. I just don't see this as a policy matter. manoj -- Some people only open up to tell you that they're closed. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#549910: debian-policy: Specify requirement in terms of upgradeability, interface stability
On Wed, Oct 07 2009, Giacomo A. Catenazzi wrote: BTW I find no reference in policy about the NEWS.Debian file. It would nice to require to document (at last for one stable release) all (also user visibe API/ABI) incompatibilities in such files. It is a goos practice, yes. Seems to me that that indicates it belongs to the developers reference? manoj -- Behold the warranty -- the bold print giveth and the fine print taketh away. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: makedev is now priority extra
On Wed, Sep 16 2009, Bdale Garbee wrote: Bug #545309 causes me to realize that the recent lowering of priority for makedev to 'extra' motivates a review and update of policy section 10.6. Given udev, the majority of Debian systems in the future are unlikely to have makedev installed at all. Actually, udev, while nice, is optional, and I think I have read reports of admins opting _not_ to have udev on the system, so in some cases one may have systems without udev and with MAKEDEV. Policy should try to support this, if we can. There may be enough usage cases for static devices to motivate keeping it around at priority extra instead of requesting it be removed entirely, but it no longer seems appropriate for policy to mandate the use of MAKEDEV. Well, if you modify that statement to unconditionally call MAKEDEV, I will agree with you. Would it be sufficient if policy makes calling MAKEDEV conditional on the existence of /sbin/MAKEDEV? Also, note that all packages above priority extra that depend on makedev are now buggy with respect to policy section 2.5. Right. But this is a different issue. manoj -- The Banana Principle: Heuristic devices don't tell you when to stop. --anonymous Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#547272: policy 5.6.16 - Format field: Is it really 1.5?
On Fri, Sep 18 2009, Raphael Hertzog wrote: Hi, On Fri, 18 Sep 2009, Giacomo A. Catenazzi wrote: In policy 5.6.16, about Format field I read: : This field specifies a format revision for the file. The most current format : described in the Policy Manual is version 1.5. The syntax of the format : value is the same as that of a package version number except that no epoch : or Debian revision is allowed - see Version, Section 5.6.12. This paragraph is completely outdated. It dates back to before 1999. At that time the Format: field was only allowed in .changes and the version was indeed 1.5. (Git history of dpkg goes back to 1996 and it was already 1.5 at that time) Changes from 1.5 to 1.6: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=bb17f303ae14541b2d5ed39d8344cb45050b385e Addition of Closes. Changes from 1.6 to 1.7: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=c95d38c8d09a248602e245f3f5ddd0f7558c79b3 Addition of Changed-By and meaning of Maintainer changed. Changes from 1.7 to 1.8: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=ce38fa696de36b1978153e5ec53535a287be3bac Addition of Checksums-*. It should tell that in .dsc it's really tied to the format of the whole source package (and not only the .dsc file) Hmm. Has this changed recently? The format field appears in a .dsc file and in the .changes file, and I assumed it referred to the format of the file it was found in, and helped in parsing the .dsc and the .changes files. However, looking over the actual files, I think that the format field means something different in .dsc and in .changes files. In .dsc files it seems to refer to the source package format (currently 1.0), however, in the .changes file, it actually does refer to the format version of the .changes file. This does mean we have to clarify the differing semantics of the Format field in different control files. In retrospect, I wish that the .dsc field had been called Src-Format, or something. and that it can be more than a version number. I assume this refers to the Format field in the .dsc file. Since policy does not currently say anything about the Format field in the .dsc file, we would need to mention any constraints on the Format field, and what the values the field may take. Can you expand on this, please? manoj -- It is easier to fight for principles than to live up to them. Alfred Adler Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: makedev is now priority extra
On Mon, Oct 05 2009, Luk Claes wrote: Manoj Srivastava wrote: On Wed, Sep 16 2009, Bdale Garbee wrote: Bug #545309 causes me to realize that the recent lowering of priority for makedev to 'extra' motivates a review and update of policy section 10.6. Given udev, the majority of Debian systems in the future are unlikely to have makedev installed at all. Actually, udev, while nice, is optional, and I think I have read reports of admins opting _not_ to have udev on the system, so in some cases one may have systems without udev and with MAKEDEV. Policy should try to support this, if we can. It's only optional in theory as if you don't use it you're totally on your own. Hmm? If we are taking that stance, why is udev still an optional package? How is the end user to know that removing an optional package would violate their warranty? manoj -- A leader is best when people barely know he exists ... When his work is done, his aim fulfilled, they will say, We did this ourselves. -- Lao-Tse Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#547272: policy 5.6.16 - Format field: Is it really 1.5?
On Mon, Oct 05 2009, Raphael Hertzog wrote: On Mon, 05 Oct 2009, Manoj Srivastava wrote: and that it can be more than a version number. I assume this refers to the Format field in the .dsc file. Yes. Since policy does not currently say anything about the Format field in the .dsc file, we would need to mention any constraints on the Format field, and what the values the field may take. Can you expand on this, please? It's a version number (major.minor) like in .changes but it can optionally be followed by a parenthesis with a name (like in 3.0 (quilt)). dpkg-source uses the major number and the content of the parenthesis to decide which perl module to use to build/unpack the source package: - 1.0 - Dpkg::Source::Package::V1 - 3.0 (quilt) - Dpkg::Source::Package::V3::quilt The minor number is left to the discretion of each module. Based on this, I think we need to explicate that the current wording in policy about Format fields only applies to the .changes file, and create a whole new section for the Format field in the .dsc file. If that sounds good, I'll see if I can whip up a wording proposal. manoj -- Let the meek inherit the earth -- they have it coming to them. James Thurber Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#391836: debian-policy: New virtual package: cron-daemon
On Thu, Oct 01 2009, Steve Langasek wrote: On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote: Hi, the bcron-run package provides /etc/crontab, which includes 24 4 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily Ok, then the bcron-run package (but not the bcron package) would meet that requirement. So. We have a criteria that would allow for anyone needing to set up a periodic cron job, and at least two packages that provide such functionality: cron, and bcron-run. Is this sufficient to add a virtual package? Given that there's demand for it, seems fine to me. Do I hear another second? Russ, do you still want policy changed, given that the requirements are so pared down now? manoj -- What makes the universe so hard to comprehend is that there's nothing to compare it with. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#391836: debian-policy: New virtual package: cron-daemon
On Mon, Oct 05 2009, Bill Allombert wrote: On Mon, Oct 05, 2009 at 10:40:02AM -0500, Manoj Srivastava wrote: On Thu, Oct 01 2009, Steve Langasek wrote: On Tue, Sep 29, 2009 at 01:43:39PM -0500, Manoj Srivastava wrote: Hi, the bcron-run package provides /etc/crontab, which includes 24 4 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily Ok, then the bcron-run package (but not the bcron package) would meet that requirement. So. We have a criteria that would allow for anyone needing to set up a periodic cron job, and at least two packages that provide such functionality: cron, and bcron-run. Is this sufficient to add a virtual package? Given that there's demand for it, seems fine to me. Do I hear another second? Russ, do you still want policy changed, given that the requirements are so pared down now? What I like to know is the use case for such virtual package. I know about popularity-contest cron.daily job, but waht about the other ? The original use case was for logfile rotation; but really, thi can be for package that needs periodic tasks to be done (devotee would like to recommend this, for the processing done during a vote -- while devotee does not set up a periodic task on install, the voting mechanism would be crippled without a periodic job execution mechanism). So, the generic use case is any periodic task execution. manoj -- Confound these ancestors They've stolen our best ideas! Ben Jonson Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file
On Mon, Oct 05 2009, Bill Allombert wrote: On Mon, Oct 05, 2009 at 12:36:44AM -0500, Manoj Srivastava wrote: Hi, I have now updated the README docs with a slightly cleaner work-flow. I would like to get a show of hands from the policy team about this; and if people are OK with this approach (using org-mode, with perhaps me committing to maintaining these documents in the team), or abandoning this approach and going to plain old HTML/docbook. Personally, I think that the .org files are easier to edit, even for people who are unfamiliar with org-mode, and are mroe readable than SGML based documents, and thus would have higher utility, but I'll abide with what the rest of the team thinks. How the synchronisation with the wiki will be handled ? Or is the wiki page deprecated ? The latter, I think. But if people want to update the wiki pages I will not stand in the way. I still did not received any patches labelled [2/4]. Well, I did: Message-Id: 1254721008-21328-3-git-send-email-sriva...@debian.org Is there is a message size limit on the list? Patch 2/4 was 3585 lines. Anyway, you can browse the full branch at: http://git.debian.org/?p=dbnpolicy/policy.git;a=shortlog;h=refs/heads/bug545548-srivasta manoj -- Atomic batteries to power, turbines to speed. Robin, The Boy Wonder Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Manoj Srivastava] [PATCH 2/4] [bug545548-srivasta]: Make upgradng-checklist a real HTML file
On Mon, Oct 05 2009, Bill Allombert wrote: On Mon, Oct 05, 2009 at 03:05:42PM -0500, Manoj Srivastava wrote: On Mon, Oct 05 2009, Bill Allombert wrote: On Mon, Oct 05, 2009 at 12:36:44AM -0500, Manoj Srivastava wrote: Hi, I have now updated the README docs with a slightly cleaner work-flow. I would like to get a show of hands from the policy team about this; and if people are OK with this approach (using org-mode, with perhaps me committing to maintaining these documents in the team), or abandoning this approach and going to plain old HTML/docbook. Personally, I think that the .org files are easier to edit, even for people who are unfamiliar with org-mode, and are mroe readable than SGML based documents, and thus would have higher utility, but I'll abide with what the rest of the team thinks. How the synchronisation with the wiki will be handled ? Or is the wiki page deprecated ? The latter, I think. But if people want to update the wiki pages I will not stand in the way. In that case, I think it would be preferable to keep a single markup language for the whole policy package. Then feel free to pick up the work, taking the language I have put in there. I'll keep the branch around, and perhaps even keep it updated. I am not interested in writing this up in debian-doc. But someone really should be writing this up, since the bug report was, in my opinion, on point: this stuff needs to be written up, and I think that the wiki stuff is already not as good as the README is when it comes to git process (far too many needless merges in that process). If someone is willing to write this up and maintain it in debiandoc, great. Or else perhaps one could reconsider my offer to maintain it in the current form. manoj -- Auction: A gyp off the old block. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
On Mon, Oct 05 2009, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: There is no consensus for the change, but I would like to underline that the directive itself is not consensusual, as some other developpers supported me in the thread on debian-devel. I think that this is a strong indication that the directive must not be a should and that the final decision must be left to the maintainer, without making his package buggy. Philosophically, I don't think this is the way that Policy changes should work, at least as decided by the Policy team rather than by the Technical Committee. The basic idea from how I look at it is that Policy uses consensus as a stabilizing factor as well as an approval process. This is typical for very conservative document maintenance, such as for standards. In order to change the document, one needs consensus, but once one has that consensus and the change has been made, that change persists not for so long as it has consensus but rather until there's consensus to change it. In other words, the barrier is to the document change, rather than approval of a specific thing the document says. At the time this change was proposed, I think it clearly had consensus (indeed, from the bug log, it was apparently unanimous). The advantage of this maintenance mechanism is that it produces a stable document. If provisions in the document are removed as soon as they don't have consensus, you can get flapping of provisions that are right on the border of a rough consensus, where they keep being added and removed. Furthermore, the Debian Constitution specifically delegates hard technical decisions to the Technical Committee, so I think it's best to follow that procedure rather than using the Policy process for changes that are contentious but that also don't seem right to just reject as not having consensus. The Technical Committee has the decision-making policies and clear statements of responsibility required to make difficult decisions, whereas the Policy process is much more open to interpretation. For the record, this reflects my views on this issue as well, manoj -- This generation may be the one that will face Armageddon. Ronald Reagan, People magazine, December 26, 1985 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
On Mon, Oct 05 2009, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Changing policy without rough consensus would require a CTTE decision on the matter. Since Russ and Manoj have both laid out their objections to changing policy by removing the should directive, I don't believe there is much hope in achieving rough consensus. [Honestly, since 3/3 of the CTTE members who have commented on this[1] have made their opinion fairly clear, I'm not sure if there's much hope in that path either.] For the record, while I supported the original Policy change and am leaning somewhat towards keeping it, I'm not firmly committed to that and could possibly have my mind changed. But I'm not really sure what line of reasoning would do it, or how best to decide. The strongest argument for changing Policy, IMO, is that the name of the binary is an interface and by changing the name of the binary, Debian is changing the interface in a way that invalidates upstream documentation and may require follow-on modifications to other programs. That's a big step to take, and I think there's a reasonable argument that this isn't a step we take necessarily in other places. We have libraries with bad ABIs that we haven't changed because while they're bad, they're not actively broken, and the compatibility is more important than fixing the design problems. Unfortunately, and I'm not sure on which side this argument falls, many of the upstream packages with this problem are generally a mess, and the language extensions aren't the only problem. Often the scripts have far too generic of names, are poorly written in other ways, or do completely bizarre things like the example that just showed up in debian-mentors of a Python program that imported another Python program in /usr/bin as a module. If we believe that the upstream API is wrong, it would generally still be a good thing to fix it for our users and downstream, this falls under improving the software we include in our OS, and in being a good citizen in the free software community (as opposed to just glorified packagers). The cut off point is the amount of pain it takes to cascade the changes down the dependent packages; if the dependency tree is shallow, I think doing the right thing would override minor conveniences (especially since renaming a script in debian/rules is trivial). If it can be show that a significant number of unrelated packages are dependent on the naming, ans we shall have to cascade the changes to these other packages, then we might want an exception. But so far, I have not seen much evidence of any significant number of unrelated packages that would be so impacted. Thus, I would be in favour of keeping the should rule as it is. manoj -- Be there. Aloha. Steve McGarret, _Hawaii Five-Oh_ Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH] bug530687-srivasta: Support for architecture wildcards
Hi, This round incorporates all the suggestions made in the last 5 days, and should read a lot better. (Re)seconds? manoj Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like all. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia mcita...@gmail.com Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 78 -- 1 files changed, 70 insertions(+), 8 deletions(-) diff --git a/policy.sgml b/policy.sgml index 0bf1001..45d6643 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: list itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. +architecture as described in ref id=arch-spec. +/item +item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. +/item itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2739,13 +2744,14 @@ Package: libc6 In the main filedebian/control/file file in the source package, this field may contain the special value ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. Specifying a specific list of architectures is - for the minority of cases where a program is not portable or - is not useful on some architectures, and where possible the - program should be made portable instead. + specific and wildcard architectures separated by + spaces. If the special value ttany/tt appears, it must + be the entire contents of the field. Most packages will + use either ttany/tt or ttall/tt. Specifying a + specific list of architectures is for the minority of + cases where a program is not portable or is not useful on + some architectures, and where possible the program should + be made portable instead. /p p @@ -2786,6 +2792,24 @@ Package: libc6 package, ttall/tt will also be included in the list. /p + p + Specifying a list of architecture wildcards indicates that +the source will build an architecture-dependent package on +the union of the lists of architectures from the expansion +of each specified architecture wildcard, and will only +work correctly on the architectures in the union of the +lists.footnote As mentioned in the footnote for +specifying a list of architectures, this is for a minority +of cases where the program is not portable. Generally, it +should not be used for new packages. Wildcards are not +expanded into a list of known architectures before +comparing to the build architecutre. Instead, the build +architecture is matched against wildcards and this package +is built if the wildcard matches./footnote If the source +package also builds at least one architecture-independent +package, ttall/tt will also be included in the list. + /p + p In a file.changes/file file, the ttArchitecture/tt field lists the architecture(s) of the package(s) @@ -4257,6 +4281,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) may also + be restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the same as + declaring restrictions using a certain set of architectures without + architecture wildcards. + For example: + example compact
Bug#518199: [7ac3ee6] Fix for Bug#518199 committed to git
tags 518199 +pending thanks Hi, The following change has been committed for this bug by Manoj Srivastava sriva...@debian.org on Sun, 4 Oct 2009 23:48:09 -0500. The fix will be in the next upload. = [virtual packages]: Added virtual packages related to the Doom game engine Added packages that support the Doom engine, a Doom engine which supports the boom feature set, and virtual packages for the corresponding data components. Closes: Bug#518199 Signed-off-by: Manoj Srivastava sriva...@debian.org Signed-off-by: Russ Allbery r...@debian.org Signed-off-by: Giacomo A. Catenazzi c...@debian.org = -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 0/4] Bug#545548: Documentation updates
Hi, I have now updated the README docs with a slightly cleaner work-flow. I would like to get a show of hands from the policy team about this; and if people are OK with this approach (using org-mode, with perhaps me committing to maintaining these documents in the team), or abandoning this approach and going to plain old HTML/docbook. Personally, I think that the .org files are easier to edit, even for people who are unfamiliar with org-mode, and are mroe readable than SGML based documents, and thus would have higher utility, but I'll abide with what the rest of the team thinks. manoj Manoj Srivastava (4): [bug545548-srivasta]: Add Documentation [bug545548-srivasta]: Make upgradng-checklist a real HTML file [bug545548-srivasta]: Arrange to regenerate derived files from org source [bug545548-srivasta]: Use a less confusing merge work-flow in the README .gitignore |1 - Makefile | 11 + Process.html | 423 Process.org| 205 ++ Process.txt| 216 ++ README-css.el | 81 + README.html| 691 ++ README.org | 359 +++ README.txt | 346 +++ debian/rules | 27 +- upgrading-checklist.html | 2373 ++-- upgrading-checklist.org| 798 +++ ...ading-checklist.html = upgrading-checklist.txt | 187 +- 13 files changed, 4950 insertions(+), 768 deletions(-) create mode 100644 Process.html create mode 100644 Process.org create mode 100644 Process.txt create mode 100644 README-css.el create mode 100644 README.html create mode 100644 README.org create mode 100644 README.txt create mode 100644 upgrading-checklist.org copy upgrading-checklist.html = upgrading-checklist.txt (87%) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 4/4] [bug545548-srivasta]: Use a less confusing merge work-flow in the README
While still minimizing unneeded merges between master and bug branches, this version of the document uses a less confusing command sequence. Also update the HTML page. Signed-off-by: Manoj Srivastava sriva...@debian.org --- README.html | 44 README.org | 38 +- 2 files changed, 53 insertions(+), 29 deletions(-) diff --git a/README.html b/README.html index 2da20e2..19608a2 100644 --- a/README.html +++ b/README.html @@ -13,7 +13,7 @@ lang=en xml:lang=en titleDebian Policy/title meta http-equiv=Content-Type content=text/html;charset=utf-8/ meta name=generator content=Org-mode/ -meta name=generated content=2009-09-15 15:48:45 CDT/ +meta name=generated content=2009-10-05 00:20:29 CDT/ meta name=author content=Manoj Srivastava And Russ Allbery/ meta name=description content=/ meta name=keywords content=/ @@ -198,14 +198,18 @@ git commit git checkout master git pull -# If there are changes in master that make the branch not apply cleanly: - : git checkout -b temp master; git merge lt;local-branch-namegt; -# If error, reset temp, merge master into local; else skip these three lines - : git reset --hard HEAD; - : git checkout lt;local-branch-namegt;; +git checkout master +git merge --no-commit lt;local-branch-namegt; +git reset --hard HEAD; +git checkout lt;local-branch-namegt;; + +# If there are changes in master that make the branch not apply cleanly, there +# should have been en error during the merge step above. If there was an +# error, merge the master branch into the local branch, fix the conflicts, and +# commit the new version of the local branch. : git merge master -# get rid of the temp branch: - : git branch -D temp +# Edit files to remove conflict + : git commit -s # Checkout the local branch, to create the patch to send to the policy git checkout lt;local-branch-namegt; @@ -491,12 +495,20 @@ git push origin bug12345-rra # update your local master branch git checkout master git pull -# If there are changes in master that make the branch not apply cleanly: -: git checkout -b temp master; git merge bug12345-rra -# If error; -: git reset --hard HEAD; -: git checkout bug12345-rra; git branch -D temp -: git merge master + +git checkout master +git merge --no-commit bug12345-rra +git reset --hard HEAD; + +# If there are changes in master that make the branch not apply cleanly, there +# should have been en error during the merge step above. If there was an +# error, merge the master branch into the local branch, fix the conflicts, and +# commit the new version of the local branch. + : git checkout bug12345-rra + : git merge master +# Edit files to remove conflict + : git commit -s + git checkout master git merge bug12345-rra # edit debian/changelog and upgrading-checklist.html @@ -671,8 +683,8 @@ reach one of the resolution states above. p class=author Author: Manoj Srivastava And Russ Allbery a href=mailto:sriva...@debian.org;lt;sriva...@debian.orggt;/a /p -p class=date Date: 2009-09-15 15:48:45 CDT/p -p class=creatorHTML generated by org-mode 6.30trans in emacs 23/p +p class=date Date: 2009-10-05 00:20:29 CDT/p +p class=creatorHTML generated by org-mode 6.31trans in emacs 23/p /div /div /body diff --git a/README.org b/README.org index 8596396..4a7458c 100644 --- a/README.org +++ b/README.org @@ -70,14 +70,18 @@ git commit git checkout master git pull -# If there are changes in master that make the branch not apply cleanly: - : git checkout -b temp master; git merge local-branch-name -# If error, reset temp, merge master into local; else skip these three lines - : git reset --hard HEAD; - : git checkout local-branch-name; +git checkout master +git merge --no-commit local-branch-name +git reset --hard HEAD; +git checkout local-branch-name; + +# If there are changes in master that make the branch not apply cleanly, there +# should have been en error during the merge step above. If there was an +# error, merge the master branch into the local branch, fix the conflicts, and +# commit the new version of the local branch. : git merge master -# get rid of the temp branch: - : git branch -D temp +# Edit files to remove conflict + : git commit -s # Checkout the local branch, to create the patch to send to the policy git checkout local-branch-name @@ -235,12 +239,20 @@ git push origin bug12345-rra # update your local master branch git checkout master git pull -# If there are changes in master that make the branch not apply cleanly: -: git checkout -b temp master; git merge bug12345-rra -# If error; -: git reset --hard HEAD; -: git checkout bug12345-rra; git branch -D temp -: git merge master + +git checkout master +git merge --no-commit bug12345-rra +git reset --hard HEAD; + +# If there are changes in master that make the branch not apply cleanly, there +# should have been en error during the merge step above. If there was an +# error, merge the master branch into the local branch
[PATCH 3/4] [bug545548-srivasta]: Arrange to regenerate derived files from org source
For machines without a newer Emacs, this has no effect, but if a new
Emacs is present, the .txt and .html files shall be regenerated if the
org file is newer.
Signed-off-by: Manoj Srivastava sriva...@debian.org
---
Makefile |2 ++
README.html | 38 +-
README.org | 15 +++
README.txt | 25 +++--
debian/rules |4 +++-
5 files changed, 44 insertions(+), 40 deletions(-)
diff --git a/Makefile b/Makefile
index d9031ff..c3e6b49 100644
--- a/Makefile
+++ b/Makefile
@@ -8,6 +8,8 @@ ifneq (,$(strip $(HAVE_ORG_EMACS)))
%.txt: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-ascii /dev/null 21
+ test $@ != README.txt ||\
+ perl -pli -e 's,./Process.org,Process.txt,g' $@
%.html: %.org
$(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
--funcall org-export-as-html-batch /dev/null 21
diff --git a/README.html b/README.html
index 765c626..2da20e2 100644
--- a/README.html
+++ b/README.html
@@ -13,22 +13,19 @@ lang=en xml:lang=en
titleDebian Policy/title
meta http-equiv=Content-Type content=text/html;charset=utf-8/
meta name=generator content=Org-mode/
-meta name=generated content=2009-09-12 17:30:48 CDT/
-meta name=author content=Manoj Srivastava/
+meta name=generated content=2009-09-15 15:48:45 CDT/
+meta name=author content=Manoj Srivastava And Russ Allbery/
meta name=description content=/
meta name=keywords content=/
-link href=/styles/simple_screen.css type=text/css rel=stylesheet
media=screen /
-link href=/styles/simple_print.css type=text/css rel=stylesheet
media=print /
-link href=/styles/common.csstype=text/css rel=stylesheet /
style type=text/css
html { font-family: Times, serif; font-size: 12pt; }
.title { text-align: center; }
p.verse { margin-left: 3% }
pre {
border: 1pt solid #AEBDCC;
-color: gainsboro;
-background-color: DarkSlateGrey;
+color: #00;
+background-color: LightSlateGray;
padding: 5pt;
font-family: Courier New, courier, monospace;
font-size: 90%;
@@ -46,8 +43,8 @@ lang=en xml:lang=en
font-weight:bold; }
body {
-color: LightSlateGray;
-background-color: #00;
+ color: DarkSlateGrey;
+ background-color: gainsboro;
font-family: Palatino, Palatino Linotype, Hoefler Text, Times New
Roman, Times, Georgia, Utopia, serif;
}
.org-agenda-date { color: #87cefa;}
@@ -179,7 +176,7 @@ Request tracker:: a
href=http://bugs.debian.org/src:debian-policy;http://bugs
pDebian Policy uses a formal procedure and a set of user tags to manage
the lifecycle of change proposals. For definitions of those tags and
proposal states and information about what the next step is for each
-phase, see PolicyChangesProcess.
+phase, see a href=./Process.htmlPolicy changes process/a.
/p
p
Once the wording for a change has been finalized, please send a patch
@@ -215,7 +212,7 @@ git checkout lt;local-branch-namegt;
dir=$(mktemp -d)
git format-patch -o $dir -s master
# check out the patches created in $dir
-git send-email --from span style=color: #ffc1c1;you lt;a
href=mailto:your#64;email;your#64;email/agt;/span \
+git send-email --from span style=font-style: italic;you lt;a
href=mailto:your#64;email;your#64;email/agt;/span \
--to debian-policy@lists.debian.org \
$dir/
/pre
@@ -328,7 +325,7 @@ In addition to the main technical manual, the team
currently also maintains:
/li
/ul
-pThese documents are maintained using the a
href=http://wiki.debian.org/PolicyChangesProcess;Policy changes process/a,
and
+pThese documents are maintained using the a href=./Process.htmlPolicy
changes process/a, and
the current state of all change proposals is tracked using the
a href=http://bugs.debian.org/src:debian-policy;debian-policy BTS/a.
/p
@@ -350,7 +347,7 @@ will involve guiding the discussion, seeking additional
input
(particularly from experts in the area being discussed), possibly
raising the issue on other mailing lists, proposing or getting other
people to propose specific wording changes, and writing diffs against
-the current Policy document. All of the steps of a
href=http://wiki.debian.org/PolicyChangesProcess;Policy changes process/a
+the current Policy document. All of the steps of a
href=./Process.htmlPolicy changes process/a
can be done by people other than Policy team members except
the final acceptance steps and almost every change can be worked on
independently, so there's a lot of opportunity for people to help.
@@ -563,7 +560,7 @@ branches. The equivalent of the following commands should
do that:
pre class=src src-Shfor i in `git show-ref --heads | awk '{print $2}'`; do
j=$(basename $i)
-if [ span style=color: #ffc1c1;$j/span != span
Re: Bug#548867: developers-reference: Improve section about developer duties
On Tue, Sep 29 2009, Raphaël Hertzog wrote: Following a discussion on debian-newmaint, I think it's important to improve the section about the duties to clearly communicate to all package maintainers (and not DD only) that the bare minimum is what I described in the pledge below (it probably needs to reformulated in the third person for integration in the devel-ref): Also, as mentioned in the discussion, the language should be made less patronizing and confrontational, and be a better fit for a standards document. --8---cut here---start-8--- Responsibilities of a Debian developer == = == = A Debian developer is responsible for properly maintaining their packages, and help maintain the quality of implementation for the OS as a whole, and to ensure that their packages integrate nicely with others and follow the Debian technical policy. Amongst other things, a Debian Developer has the responsibility to help in releasing a stable version the OS, which includes: - Work with the release team towards making the release happen - Keep the packages under their control free of release critical bugs, and work on RC bugs in a timely fashion - Release critical bugs should be considered to be amongst the highest priority tasks that the developer has in Debian - If timely response is not possible (due to time constraints, for example), this status should be mentioned clearly in the associated bug reports, and these reports should be tagged help. - RC bugs that are difficult to correct should be tagged help The developer also has the responsibility to work with the security and stable release teams and help provide updated packages for the stable and/or testing releases as needed. If the developer has time, and ability, they should also help their fellow developers deal with release critical bugs, by providing patches, and if necessary by doing NMU's (see NMU procedures elsewhere in this document) Release critical bugs need to ber fixed ASAP, and they are automatic invitations for bug fixing NMU's, and long standing RC bugs make the package unsuited for release, and lack of attention to RC bugs is grounds for the QA team to orphan the package. --8---cut here---end---8--- The other bits about recognizing their lack of ability and rubbing their faces in their own failure sound kind of pompous, and are unsuited for a high quality standards document, in my opinion. manoj -- Bond reflected that good Americans were fine people and that most of them seemed to come from Texas. -- Ian Fleming, Casino Royale Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Mon, Sep 21 2009, Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: ok. fair enough. BUT: the original proposal and this proposal contain only the duet: + A package may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvarcpu/var/tt. footnoteInternally, the package The triplets are listed only in the footnote (which is IMHO confusing). But if we want to support the klibc (and in general different libc ABI), as it seems nice, this proposal should be more explicit about the use of triplet, allow them in the usual places, and policy should set the default value. Yes, I think I agree with all of that. Any suggestions on the wording? I was treating this proposal as merely reserving the namespace, and a later proposal coming forth with actual details of the usage, when multi-arch is further along. So, unless there are objections, I would like to see the wording changes go in now, with clarifications added as and when multi-atch solidifies. manoj -- Backed up the system lately? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#391836: debian-policy: New virtual package: cron-daemon
On Fri, Sep 18 2009, Steve Langasek wrote:
Hmm. You do have a point. However, the original use case was
for a package to be able to have it's log files rotated periodically,
and by that criteria cron, anacron, fcron, and bcron do fit the bill.
I think perhaps we need to pare down the requirements (and
perhaps change the name of the virtual package), so that packages that
just want a periodic job scheduler don't have to specify a list of
matching providers.
Requirements:
1) Be able to run a batch job periodically.
2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
On Thu, Sep 17, 2009 at 09:03:22AM +, Gerrit Pape wrote:
On Wed, Sep 16, 2009 at 10:32:04PM -0700, Steve Langasek wrote:
fcron doesn't appear to run cron.daily by default, and neither does bcron.
*Only* the cron package ships a crontab that runs /etc/cron.daily by
default; anacron also supports running cron.daily, but relies on cron
itself
to trigger it on a daily basis. (Without cron installed, anacron will only
rotate logs when you reboot.)
Hi, the bcron-run package provides /etc/crontab, which includes
24 4 * * * root test -x /usr/sbin/anacron || run-parts --report
/etc/cron.daily
Ok, then the bcron-run package (but not the bcron package) would meet that
requirement.
So. We have a criteria that would allow for anyone needing to
set up a periodic cron job, and at least two packages that provide such
functionality: cron, and bcron-run.
Is this sufficient to add a virtual package?
manoj
--
The little pieces of my life I give to you, with love, to make a quilt
to keep away the cold.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
Hi, Given that there have been no objections or wording change suggestions, I would like to ask for seconds on this. manoj Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like all. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia mcita...@gmail.com Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 80 +++--- 1 files changed, 70 insertions(+), 10 deletions(-) diff --git a/policy.sgml b/policy.sgml index 0bf1001..6624f33 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: list itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. +architecture as described in ref id=arch-spec. +/item +item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. +/item itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2737,15 +2742,16 @@ Package: libc6 p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. Specifying a specific list of architectures is - for the minority of cases where a program is not portable or - is not useful on some architectures, and where possible the - program should be made portable instead. + package, this field may contain either the special value + ttany/tt, or the special value ttall/tt, or a list of + specific and wildcard architectures separated by + spaces. If the special ttany/tt appears, it must + be the entire contents of the field. Most packages will + use either ttany/tt or ttall/tt. Specifying a + specific list of architectures is for the minority of + cases where a program is not portable or is not useful on + some architectures, and where possible the program should + be made portable instead. /p p @@ -2786,6 +2792,22 @@ Package: libc6 package, ttall/tt will also be included in the list. /p + p + Specifying a list of architecture wildcards indicates that +the source will build an architecture-dependent package on +the union of the lists of architectures from the expansion +of each specified architecture wildcard, and will only +work correctly on the architectures in the union of the +lists.footnote As mentioned in the footnote for +specifying a list of architectures, this is for a minority +of cases where the program is not portable. Generally, it +should not be used for new packages. Also note that the +wildcards are not expanded then compared, they are simply +matched. /footnote If the source package also builds at +least one architecture-independent package, ttall/tt +will also be included in the list. + /p + p In a file.changes/file file, the ttArchitecture/tt field lists the architecture(s) of the package(s) @@ -4257,6 +4279,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) may also + be restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the same as + declaring restrictions using a certain set of architectures without + architecture wildcards. + For example: + example compact=compact
Re: Bug#491318: init scripts should support start/stop/restart/force-reload - why not must?
On Mon, Sep 14 2009, Henrique de Moraes Holschuh wrote: On Fri, 11 Sep 2009, Manoj Srivastava wrote: Looking at the bug report, it seems like we agree that the current policy is correct, and the should should not be changed to a must? In that case, can we just close this report? Alternatively, the proposal should be clarified to mention that it is optional for system startup scripts (runlevel S), but mandatory for everyone else. Daemon and regular service initscripts really ought to implement all actions, and do so *sensibly*. Would you care to suggest wording to the effect? manoj -- Penn's aunts made great apple pies at low prices. No one else in town could compete with the pie rates of Penn's aunts. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: debian-policy package should include a pointer to http://wiki.debian.org/PolicyChangesProcess
On Tue, Sep 15 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: These series of patches add easy to edit sources for a README file, for documenting the Policy change process, and finally, the upgrading checklist. The source format is designed to be easy to read and edit, and is rendered into a pretty text format, as well as HTML, as long as a recent versionof Emacs is found. The rendered files are shipped in the package to avoid a build dependency on Emacs; the idea is that policy editors have emacs isntalled and pre-create the rendered files before release, kind of like the bad old days of autotools. I'm okay with that, personally. It'll give me something new in Emacs to play with. It's not entirely ideal, but if it's expedient, I have no problems. In the long run, using something like Markdown or reStructured Text for documents like this that aren't full manuals might be a good idea. Well,I can't live without the getting things done stuff in org mode, and I do find raw org-mode more readable than markdown or ReST, but I have no objections if someone converts these docs to the formats you mentioned. On Tue, Sep 15 2009, Bill Allombert wrote: Well I do not have emacs installed... That could be an issue. Well, I would be willing to take over the burden of maintaining these documents; and for the README and Process documents this is not much of an issue (we hardly ever change them), but it could be a problem with the upgrading-checklist.org, if you think emacs23 is too big a beast for you. Did you by any chance numbered your patches 0/3, 1/3 and 3/3 ? Did that count as one 'Manoj Wonderful Typo' (MWT) ? The mails were generated by git send-email, so I don't think that was the case. Perhaps it got eaten by a spam filter? So, I am pushing out the branch bug545548-srivasta out, y'all can do the diff yourself. I rebased it against latest master before pushing. manoj -- The second best policy is dishonesty. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#391836: debian-policy: New virtual package: cron-daemon
On Fri, Sep 11 2009, Steve Langasek wrote:
On Fri, Sep 11, 2009 at 12:54:10AM -0500, Manoj Srivastava wrote:
Are there any seconds to the proposal to create a virtual
package cron-daemon? The rationale is for packages like logratate,
which otherwise would need to depend on cron | anacron | fcron | bcron |
etc.
Given how anacron works, I think it fails almost all of the
requirements below, so should not be eligible to declare this virtual
package. fcron's Conflicts / description suggest it may have a
similar problem. Is this virtual package still useful in that case?
Hmm. You do have a point. However, the original use case was
for a package to be able to have it's log files rotated periodically,
and by that criteria cron, anacron, fcron, and bcron do fit the bill.
I think perhaps we need to pare down the requirements (and
perhaps change the name of the virtual package), so that packages that
just want a periodic job scheduler don't have to specify a list of
matching providers.
Requirements:
1) Be able to run a batch job periodically.
2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
These schedulers claim to be drop in replacements of Vixie cron:
cron, bcron
fcron says that is implements most of what Vixie cron does; but
does not claim to be a drop in replacement.
Anacron does not seem to make any claims about vixie cron
compatibility at all.
However, all of them should meet the bill, as far as the
original use case goes.
manoj
--
Hope that the day after you die is a nice day.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: debian-policy package should include a pointer to http://wiki.debian.org/PolicyChangesProcess
Hi, So, the previous version of the checklist html was messed up; and so I have put fixed version of the file at: http://people.debian.org/~srivasta/checklist.html manoj -- Maternity pay? Now every Tom, Dick and Harry will get pregnant. Malcolm Smith Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: [PATCH 3/3] [bug545548-srivasta]: Arrange to regenerate derived files from org source
For machines without a newer Emacs, this has no effect, but if a new Emacs is present, the .txt and .html files shall be regenerated if the org file is newer. Signed-off-by: Manoj Srivastava sriva...@debian.org --- debian/rules |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/debian/rules b/debian/rules index 393c1f1..dcf5e91 100755 --- a/debian/rules +++ b/debian/rules @@ -83,7 +83,9 @@ make_directory := install -p -d -o root -g root -m 755 all build: stamp-build -stamp-build: version.ent $(sanitycheck) +stamp-build: version.ent $(sanitycheck) upgrading-checklist.html \ + upgrading-checklist.txt README.txt README.html \ + Process.txt Process.html $(MAKE) $(SGML_FILES:=.sgml.validate) \ $(SGML_FILES:=.html.tar.gz) \ $(SGML_FILES:=-1.html) \ -- 1.6.3.3 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: [PATCH 0/3] debian-policy package should include a pointer to http://wiki.debian.org/PolicyChangesProcess
Hi, These series of patches add easy to edit sources for a README file, for documenting the Policy change process, and finally, the upgrading checklist. The source format is designed to be easy to read and edit, and is rendered into a pretty text format, as well as HTML, as long as a recent versionof Emacs is found. The rendered files are shipped in the package to avoid a build dependency on Emacs; the idea is that policy editors have emacs isntalled and pre-create the rendered files before release, kind of like the bad old days of autotools. Of course, we can just add emacs23 to the build depends, and strip the generated files from the Package, I'm game either way. Three patches follow. Feedback appreciated. Manoj Srivastava (3): [bug545548-srivasta]: Add Documentation [bug545548-srivasta]: Make upgradng-checklist a real HTML file [bug545548-srivasta]: Arrange to regenerate derived files from org source .gitignore |1 - Makefile |9 + Process.html | 423 Process.org| 205 ++ Process.txt| 216 ++ README-css.el | 81 + README.html| 683 ++ README.org | 348 +++ README.txt | 341 +++ debian/rules | 27 +- upgrading-checklist.html | 2373 ++-- upgrading-checklist.org| 798 +++ ...ading-checklist.html = upgrading-checklist.txt | 187 +- 13 files changed, 4924 insertions(+), 768 deletions(-) create mode 100644 Process.html create mode 100644 Process.org create mode 100644 Process.txt create mode 100644 README-css.el create mode 100644 README.html create mode 100644 README.org create mode 100644 README.txt create mode 100644 upgrading-checklist.org copy upgrading-checklist.html = upgrading-checklist.txt (87%) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: debian-policy package should include a pointer to http://wiki.debian.org/PolicyChangesProcess
On Sat, Sep 12 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: Fair enough. I am including a README.txt (I also have a README.html from the same source, which I am not posting here, in order not to get distracted by font and color issues). How does the following look? I suspect that the process document is even more important than the mechanics of maintenance, although it does make sense to me to have both of them in the package. I'll encode that one in as well, and see about the hyperlink. I'm not a big fan of wikis in general -- I mostly use them with minor grumbling when the people I'm working with want them -- My sentiments exactly. so I'm happy personally to have all this information canonically live in the debian-policy package instead of the wiki. But we obviously don't want to try to maintain it in two places. Were you thinking of turning the wiki page into a pointer to the package, or did you have a cross-conversion or cross-update method in mind? I am writing the sources of this in a mode that I can turn into text as well as html, and I was planning on just adding it to the html files produced by the policy package, as well as a set of .txt files in /usr/share/doc. Once we have released that, and the html files are live on the web, we can turn the wiki pages into pointers to them. I would be happy to maintain these documents in the package itself, and we can decide on the css (my current css received a number of negative reviews about fonts and colors, but I am sure there are plenty of people who can who can show me the error of my ways here). I'll send another email with the process document as text/xhtml) manoj -- To give of yourself, you must first know yourself. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#392479: Request for virtual package ircd
Hi, This is yet another virtual package request I have some reservations about. There was a long thread on -devel starting at: http://lists.debian.org/debian-devel/2006/10/msg00483.html Several objections were raised: a) IRC services do not need to depend on a daemon (they may be remote). So it is unclear which problem an ircd virtual package would solve. There is no clear rationale provided with the bug report. Indeed, there is nothing in the archive that depends on the virtual package ircd. b) Multiple ircd daemons need not conflict with one another, since they can all be configured to run on different ports, so the conflict with and provide ircd scenario does not seem to come into play. There are legitimate use cases for having multiple ircd's installed (just like one may install multiple web servers) c) In an email in that thread, the OP has conceded that the virtual package name might not be a good idea after all. So, there were few arguments made in favour of the virtual package, and there seems to have been a fairly strong consensus that the virtual package was not needed, and would provide no benefit. Given that, I would like to close this report, without providing the virtual package, unless some Rationale is provided. manoj -- If pregnancy were a book they would cut the last two chapters. Nora Ephron, Heartburn Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#391836: debian-policy: New virtual package: cron-daemon
Hi,
Are there any seconds to the proposal to create a virtual
package cron-daemon? The rationale is for packages like logratate,
which otherwise would need to depend on cron | anacron | fcron | bcron |
etc.
The requirements for providing cron-daemon are:
[ POSIX ]
- Has to provide /usr/bin/crontab and support crontab entries
[ Implemented in most Linux / BSD distributions, including Debian, but not
in Solaris, HP-UX or AIX's cron ]
- Correct execution of /etc/cron.d
- Correct support of /etc/crontab
- Correct support of /etc/cron.{allow,deny}
- Has to support 'crontab -u'
- Support of crontab entries with extended features (i.e. those in Vixie
Cron need to be supported), these include names for days and months,
ranges, step values and the 'special strings' (@reboot, @yearly..)
[ Debian-specific feature ]
- Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
Do I hear seconds for this package?
manoj
--
Elevators smell different to midgets.
Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491318: init scripts should support start/stop/restart/force-reload - why not must?
Hi, Looking at the bug report, it seems like we agree that the current policy is correct, and the should should not be changed to a must? In that case, can we just close this report? If not, can some reason be provided why policy should be changed? manoj -- Adults die young. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Fri, Sep 11 2009, Peter Pentchev wrote: On Thu, Sep 10, 2009 at 04:28:55PM -0500, Manoj Srivastava wrote: Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like all. [snip] +lists.footnote As mentioned in the footnote for +specifying a list of architectures, this is a settings for A minor point, but should this not be a setting? Thanks, fixed locally. +a minority of cases where the program is not +portable. Generally, it should not be used for new +packages. Also note that the wildcards are not expanded +then compared, they are simply matched. /footnote If If there are no substantive objections to this wording, I'll send in the new version and ask for seconds in a day or so. manoj -- The meek are contesting the will. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#525843: support for encoding long descriptions using a standard text-based markup language
On Fri, Sep 11 2009, Stefano Zacchiroli wrote: On Thu, Sep 10, 2009 at 05:43:01PM -0500, Manoj Srivastava wrote: We could, as an example, go by pop-con results for the interpreters -- that is one defensible means of selecting the language, I guess. Or, we can setup the first devotee-based authoritative polls among DD. It can be an interesting first use case. If you agree, I can have set it up, based on my own devotee branch we discussed, early next week. How about it? Heh. You're just itching to try out your changes, aren't you? Go for it. manoj -- The lunatic, the lover, and the poet, Are of imagination all compact...-- Wm. Shakespeare, A Midsummer Night's Dream Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518199: debian-policy: virtual package names for doom-related packages
On Thu, Sep 10 2009, Manoj Srivastava wrote: Hi, The most recent version of this proposal was: --8---cut here---start-8--- --- virtual-package-names-list.txt~ 2009-03-15 18:19:17.0 + +++ virtual-package-names-list.txt2009-03-15 18:20:00.0 + @@ -179,6 +179,17 @@ scheme-srfi-55 Scheme interpreter accepting the SRFI 55 language extension +Games and Game-related +-- + + doom-engine An executable Doom engine + boom-engine An executable Doom engine supporting the 'boom' + feature-set + doom-wadThe data component of a Doom game, compatible with + the original Doom engine + boom-wadThe data component of a Doom game, using features + from the boom engine family + Old and obsolete virtual package names -- Note, that no other package then the ones listed here should use --8---cut here---end---8--- Oh, I forgot to second this myself. manoj -- Progress was all right. Only it went on too long. James Thurber Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgp6pkmkXcs15.pgp Description: PGP signature
Bug#525843: support for encoding long descriptions using a standard text-based markup language
Hi, There are some differences in how thee systems define lists; and I think markdown is more forgiving with simple lists Consider that continuing lines in markdown lists do not have to be aligned after the white space: Markdown --8---cut here---start-8--- * blah blah blah more blah blah is fine --8---cut here---end---8--- restructured. --8---cut here---start-8--- * blah blah blah more blah blah needs to be precisely aligned --8---cut here---end---8--- Numbered list in markdown do not have to be sequential, but in Rst you use #. or you need to have them sequential. On the other hand, rst is way better with definition lists or field lists; I just think that plain lists are more likely to belong in a description field. Block quotes in Rst are just indented paragraphs, and seem closer to the behaviour we currently have (Markdown uses to do block quotes) . Advantage Rst here, I think. So, here is my take on a subset that needs to be supported in policy (I do not think we need titles, don't you agree?) a) Unordered lists use asterisks, pluses, and hyphens — interchangeably — as list markers. b) Ordered lists use numbers followed by periods. 1) The numbers need not be i sequence -- but you should still start the list with the number 1. 2) The numbers need to be in sequence -- but may use #. instead to get auto numbering. c) List markers typically start at the left margin, but may be indented by up to three spaces. List markers must be followed by one or more spaces or a tab. d) A hyperlink reference may directly embed a target URI inline, within angle brackets: http://www.debian.org e) nested lists are created by indenting the nested list 1) by at least 4 spaces, or 2) have a blank line above, and line up with the previous paragraph. f) List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must 1) have its first line indented by at least 4 spaces, or 2) must line up with the paragraph above, relative to the bullet marker g) Emphasis is provided by surrounding the text with '*'. Like *emphasis*. Stronger emphasis is provided by doubling the '*' -- like **strong**. Once we decide on which language to use, I can tighten up the spec above. By sticking to these conventions, I think the plain text description is readable, and indeed, conveys the intent. manoj -- Honesty is for the most part less profitable than dishonesty. Plato Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like all. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia mcita...@gmail.com Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 81 +++--- 1 files changed, 71 insertions(+), 10 deletions(-) diff --git a/policy.sgml b/policy.sgml index 844053d..69c0bcf 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: list itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. +architecture as described in ref id=arch-spec. +/item +item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. +/item itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2737,15 +2742,16 @@ Package: libc6 p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. Specifying a specific list of architectures is - for the minority of cases where a program is not portable or - is not useful on some architectures, and where possible the - program should be made portable instead. + package, this field may contain either the special value + ttany/tt, or the special value ttall/tt, or a list of + specific and wildcard architectures separated by + spaces. If the special ttany/tt appears, it must + be the entire contents of the field. Most packages will + use either ttany/tt or ttall/tt. Specifying a + specific list of architectures is for the minority of + cases where a program is not portable or is not useful on + some architectures, and where possible the program should + be made portable instead. /p p @@ -2786,6 +2792,23 @@ Package: libc6 package, ttall/tt will also be included in the list. /p + p + Specifying a list of architecture wildcards indicates that +the source will build an architecture-dependent package on +the union of the lists of architectures from the expansion +of each specified architecture wildcard, and will only +work correctly on the architectures in the union of the +lists.footnote As mentioned in the footnote for +specifying a list of architectures, this is a settings for +a minority of cases where the program is not +portable. Generally, it should not be used for new +packages. Also note that the wildcards are not expanded +then compared, they are simply matched. /footnote If +the source package also builds at least one +architecture-independent package, ttall/tt will also +be included in the list. + /p + p In a file.changes/file file, the ttArchitecture/tt field lists the architecture(s) of the package(s) @@ -4257,6 +4280,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) may also + be restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the same as + declaring restrictions using a certain set of architectures without + architecture wildcards. + For example: + example compact=compact +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + /example + is equivalent
Bug#525843: support for encoding long descriptions using a standard text-based markup language
package debian-policy user debian-pol...@packages.debian.org usertag 525843 = normative discussion thanks Hi, Looking at the bug report, I can agree that there is a rough consensusabout using a standard text-based markup language to interpret package long descriptions. What is unclear, though, which of the two equivalent languages (Markdown or ReStructured Text) are being proposed here -- either one of these would be acceptable, and there are working implementations of either that seem to do a very creditable job. We need to pick one or the other (and at this point, I am agnostic to whatever is picked, since either is a standard that is popular and is not a NIH spec) -- and I do not see anything claer about which one policy should support. We could, as an example, go by pop-con results for the interpreters -- that is one defensible means of selecting the language, I guess. manoj ps: people on the mailing list who are not conversant with this bug are encouraged to follow the links in the initial bug report and the followup before making their minds on this -- Random, n.: As in number, predictable. As in memory access, unpredictable. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518199: debian-policy: virtual package names for doom-related packages
Hi, The most recent version of this proposal was: --8---cut here---start-8--- --- virtual-package-names-list.txt~ 2009-03-15 18:19:17.0 + +++ virtual-package-names-list.txt 2009-03-15 18:20:00.0 + @@ -179,6 +179,17 @@ scheme-srfi-55 Scheme interpreter accepting the SRFI 55 language extension +Games and Game-related +-- + + doom-engine An executable Doom engine + boom-engine An executable Doom engine supporting the 'boom' + feature-set + doom-wadThe data component of a Doom game, compatible with + the original Doom engine + boom-wadThe data component of a Doom game, using features + from the boom engine family + Old and obsolete virtual package names -- Note, that no other package then the ones listed here should use --8---cut here---end---8--- Can we have a show od seconds, please? Normally I would not ask for a virtual package name proposal to go through a rounds of seconds, but there was an extended discussion on this, and I want to be sure that there is consensus that the issues raised have been addressed. I would like to point out that these virtual names are already being used in the wild by a small group of related packages. manoj -- Your attitude determines your attitude. Zig Ziglar, self-improvement doofus Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545688: debian-policy: Include webapps policy in external sub-policy documents
On Tue, Sep 08 2009, Neil McGovern wrote: We've now got to the stage where we seem to have a good webapps policy in place, and would like to have it included in policy main as a 'sub-policy' document. For reference, it's at http://webapps-common.alioth.debian.org/draft/html/ I looked at the document, and, as it correctly say up front, it: This manual aims to clarify the standards and technical requirements for web-based software in the Debian GNU/Linux distribution. It also serves as packaging manual with examples of best practices for packaging web applications in Debian. I feel the former belongs in policy, the latter needs to be split off and either added to the dev ref, or remain as a standalone documentation. Would you like to take a crack at pulling out the normative parts of that manual, perhaps with a wee bit of rationale, and see where we stand? manoj -- They also surf who only stand on waves. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545548: debian-policy package should include a pointer to http://wiki.debian.org/PolicyChangesProcess
On Mon, Sep 07 2009, Steve Langasek wrote: The debian-policy change process doesn't seem to be linked from anywhere in the debian-policy package (or the policy git repo). It would be good to have a pointer to it, to tie this all together. ok. I looked at the Wiki, and I found that the policy team page has lots of information about the policy package, including the change process. How about adding: Homepage: http://wiki.debian.org/Teams/Policy manoj -- Slous' Contention: If you do a job too well, you'll get stuck with it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470633: Explicitly say obsolete configuration files may be removed
Hi, This bug has not been looked at for a while. The wiki article: states: ,[ http://wiki.debian.org/DpkgConffileHandling ] | If you completely remove a configuration file, you should make sure | it's also removed from the disk. However if the user has modified it, | then you have to preserve the user's modifications somehow in case | they wish to refer to them (see also Policy 10.7.3). | | This can be done your preinst script when given the install or upgrade | argument with a package version known to have the conffile that has | been removed. ` I do think this makes sense, and is definitely a good practice (and thus belongs in the developers reference, at least, if not in policy proper. The argument I see for having it in policy proper is that a conffile left behind which is no longer used has potential for confusion, not only for humans, but other packages that may parse the configuration. I also think we should consider what happens if the package is subsequently purged; in that case, all the conffiles it uses are purged -- but the conffile it no longer uses is left behind as cruft in the system, which seems like a flaw. manoj -- There's no such thing as pure pleasure; some anxiety always goes with it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04 2009, Emilio Pozuelo Monfort wrote: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. This was my understanding, though I se that policy never states that explicitly. (However, policy is not exhaustive either, and things are added as the need arises). I note that the first hit for Native in policy states: --8---cut here---start-8--- Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should always use the MMDD format. --8---cut here---end---8--- Admittedly, this is in a section talking about version numbers based on dates. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. Also, where should they report bugs? In bugs.debian.org? Right. And what if the maintinership passes to a non-dd? Policy remarks on this in a informational footnote: --8---cut here---start-8--- [2] Although there is nothing stopping an author who is also the Debian maintainer from using this changelog for all their changes, it will have to be renamed if the Debian and upstream maintainers become different people. In such a case, however, it might be better to maintain the package as a non-native package. --8---cut here---end---8--- Native packages make sense when the package is pretty much only useful for Debian (and Debian derivatives), e.g. dpkg or apt, but not for unrelated packages. Sounds good to me. manoj -- The farther you go, the less you know. Lao Tsu, Tao Te Ching Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Wed, Aug 26 2009, Steve Langasek wrote: On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote: Given that devscripts, lintian, and the dev-ref all advocate or implement +nmu\d+, and that debhelper and cdbs look at the hyphen for determining native vs non-native, I have tried to do so. I think the proposed practice is strictly better than not specifying any conventions, and where possible, Ihave tried to stick to best practices as documented in the dev-ref to base policy on. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. I don't agree that this is something that should be recommended. Changing the convention for NMU versioning of non-native packages is not necessary in order to correct the use of confusing version numbers for NMUs of native packages. If the dev-ref is recommending +nmuN for non-native packages, then I think that's a bug in the dev-ref - a common enough problem given the lack of a public process for dev-ref change reviews. I think they changed that in a newer release than the one referred to in the bug report I saw. Recommending use of +nmuN for native packages seems like an appropriate thing for Policy to standardize, since using hyphens makes the package versions appear non-native and appending .N to the version collides with ordinary versioning conventions for native packages. So, we should have: , | Format: | Version:= [epoch`:']upstream_version[`-'debian_revision] | Native Package NMU's: | Version =~ m/\+nmu\d+$/ | Binary Only NMU's: |Version =~ m/\+b\d+$/ ` The next tgree are tentative: , | Non-native package NMU: |Version =~ m/\-\.\d+$/ ` This is tentative since I can't see why we need to outlaw packages adding \+nmu\d+ even on non-native packages. Perhaps policy should butt out here, if the pattern is different for non-native NMU's than for Native package NMU's. , | Stable Security NMU's |Version =~ m/\+deb\d\d.\d+$/ | Testing Security NMU's | Version =~ m/\+debt\d\d.\d+$/ ` These last two do not have buy in from the security team, as far as I can tell. How does that sound? manoj -- Most people's favorite way to end a game is by winning. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#542865: Grant an FHS exception for the multiarch library directories
On Fri, Aug 21 2009, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On Fri, Aug 21, 2009 at 03:47:24PM -0700, Russ Allbery wrote: It looks good to me as a first step. Seconded, with the caveat that we probably don't want to release this with Policy until we've hammered out any specific restrictions on how those directories can be used first. I think the only specific restriction needed is already spelled out - that packages can only install to the triplet matching their own architecture. Are there other restrictions that you think are called for? The current restriction is specific to libraries. Don't we need to say that you can't put *any* files into any triplet directory that isn't for your package architecture? Hmm. My first read was that one could not put anything that was not a library in these directories, but perhaps it should be stated explicitly. manoj -- It's like deja vu all over again. Yogi Berra Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Thu, Aug 20 2009, Steffen Joeris wrote: I haven't followed all the discussion around this, so please excuse my ignorance, but could someone try and explain to me in simple terms what we are trying to fix with all this policy stuff around versioning? I don't see why we have to replace our usual convention of: - Add a .X for normal NMUs (including security NMUs to unstable/experimental) - Add +$codenameX to uploads for oldstable/stable/testing (for security and non-security, regardless of whether NMU or MU) The only problem I could think of is when we start having a codename that starts with a, since the binNMU convention is to add +bX. But I'd worry about that problem, when it arises (is there a toy story character starting with a? :) ). Well, it started with there being some confusion on what determining what was a native package, based on version numbers: and it turns out that while policy is clear about the distinction of an upstream version part and a Debian specific revision part (and, personally, it ought to follow that for a native package there is no Debian specific version, since it is all Debian specific), because of a practice some packages had of appending -0.1 for NMU's of native packages, making it impossible to tell if it was the NMU of a non-native package, or the NMU of a native package, without looking into the .dsc. This is unnecessarily hard, so some policy language carving out a name space for NMU's would be nice. Then there as the issue of NMU vs codename specific NMU's (like security or backports), +codename\d might lexically sort before +conename++\d, if codename ++ sorts earlier. So coming up with +deb and +debt seems to stave off future issues with versions not sorting correctly. This also makes new NMU's sort later than older codename specific uploads. There is a preponderance of best practices already in play, and putting them into policy just gives them greater weight, and makes it possible for tools to depend on these naming rules. The one issue I see is that +nmu\d is not common for non-native NMU's, though I think a consistent scheme is to be preferred, for ease of implementation in tools and grep-dctrl searches. I am tempted to still recommend +nmu\d as the version suffix for any NMU, end have lintian gently warn about it. My opinion is that it is regrettable if we went the route of the popular choice rather than the slightly better technical one, even if it is not the vogue; since I think that having a dependable, and simple, rule would be useful enough. Your mileage may vary. I also understand that there are a myriad of choices we may make about naming, most of which are technically viable, but I think this is precisely the role for policy, to make a decision between several equally viable technical choices, if it helps integration and tools. manoj -- An ignorant man ages like an ox. His flesh may increase, but not his understanding. 152 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Wed, Aug 19 2009, Raphael Hertzog wrote:
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Additionally,
§ 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
applicable
§ C.1.1. `dpkg-source' states that it creates a diff.gz if
appropriate, and looks at the diff.gz while extracting if
applicable.
Heh, reading this remind me that policy should probably be updated to
reflect the new source package formats... (diff.gz can also be
debian.tar.ext, etc.)
I think appendix C is mostly stuff that is not normativce, and is
only around until it can be incorporated into dpkg documentation. If
you think all the material in that appendix is currently available in
dpkg, we can just drop appendix C from policy.
Given these, I read this as letting the tools rely on
the following invariants, even though these are not explicitly spelled
out in so many words in policy:
1) If there is a - in the version number, then the package is
non-native
a) the upstream version is the part of the string until the last
'-' in the version number
b) there is a .orig.tar.gz and
c) diff.gz referenced in the .dsc
2) If there is no '-' in the version number, then the package is a
debian native package
a) there is no debian revision, all the version number is the
upstream version number
b) there is a tar.gz and no diff.gz in the .dsc file
There's no such invariant although it's a recommended practice:
http://lintian.debian.org/tags/native-package-with-dash-version.html
That is correct. (I thought that there would be other
references in dev-ref or policy, but if there are I missed them, but
you may add that if you have a '-' in the version number, debhelper
seems to think it should not be native)
This proposal is to take current best practice and move it into
policy, since standardization here would help tools and users
And the type of file associated is going to be different once the archive
accepts new source formats.
Format: 1.0 accepts either .tar.gz or (.diff.gz + orig.tar.gz)
Format: 3.0 (native) allows .tar.{gz,bz2,lzma}.
Format: 3.0 (quilt) allows debian.tar.{gz,bz2,lzma} +
orig.tar.{gz,bz2,lzma} + optionals orig-foo.tar.{gz,bz2,lzma}
dpkg-source doesn't impose any restriction on the package's version
when using any of those formats.
OK. I was not planning on adding the above to policy anyway,
just to express my understanding of the current state, but thanks for
pointing out that the above understanding fails to take into account
the new package format.
You are correct in that policy should not contain anything that
goes against the new package formats.
1) dch --nmu adds +nmu1 for native packages
2) +nmuX is already supported by devscripts and lintian.
3) the developers reference also advocates adding +codename\d+. It
also advocates using exactly the same tar.gz file as already in the
archive.
While I would like us to standardize on +nmuX for all NMU, there's no
general consensus here. The developers-reference has changed again the
recommendation to match the dch --nmu practice:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532945
Now I believe that consistency here would be a win that is more important
than the ugliness or aesthetic problem that some DD seem to have with this
convention. I don't know if the discussion during the policy process can
lead to agreement on this.
This could be a problem. I would prefer a succinct rule for the
tools to rely on (even if it will take a while). Do you think if
policy recommended \+nmu\d+ and lintian had a warning, this might
change? Or should policy leave it alone?
A corresponding name space can be carved out for security
uploads. Obviously a solution would be to add +debion.counter, where
version should be anything that sorts correctly, such as the current
stable version with something added if the upload is to testing.
\+deb\d\d.\d+
\+debt\d\d.\d+ (testing only, sorts ahead of stable)
where
1.0.1 --old-- 1.0.1+etch1 -- 1.0.1+deb40
1.0-1 --old-- 1.0.1+etch1 -- 1.0-1+deb40
(sarge -- deb31, etch --deb40, lenny -- deb50)
We had this discussion in the threads that discussed DEP1 on -project.
We did not reach a consensus (with the security team) here.
Subthread starting here:
http://lists.debian.org/debian-project/2008/08/msg00136.html(Thijs is part of
the security team)
But I also think that it would be nice to have a working long-term
solution and I would be in favor of such a scheme. The main objection was
that we do not know the next version in advance and the release team
has changed this fact, we already know that squeeze will be 6.0 and it
should stay the same in the future as the reasoning of this was to
facilitate the work
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
to developers reference changing its recommendation. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 I propose that we carve out a version number space that reserves a suffix match of \+nmu\d+$ for packages that are NMU's, and make this invariant for native and non-native packages. 1.0.1 -- 1.0.1+nmu1 1.0-1 -- 1.0-1+nmu1 And NMU's can be distinguished by a simple regexp match. -- Similarly, for a recompilation or binary only NMU (common use case: outdated build environment, no source changes), the suffix can be \+b\d+$. This does require and modification of the changelog, so that the version number is changed (and thus the new package is used to upgrade the older, broken package). a) the developers reference already advocates this b) this is seen as a magic version number by the archive maintenance tools, and the upload is not rejected for not having sources. 1.0.1 -- 1.0.1+b1 1.0-1 -- 1.0-1+b1 -- A corresponding name space can be carved out for security uploads. Obviously a solution would be to add +debion.counter, where version should be anything that sorts correctly, such as the current stable version with something added if the upload is to testing. \+deb\d\d.\d+ \+debt\d\d.\d+ (testing only, sorts ahead of stable) where 1.0.1 --old-- 1.0.1+etch1 -- 1.0.1+deb40 1.0-1 --old-- 1.0.1+etch1 -- 1.0-1+deb40 (sarge -- deb31, etch --deb40, lenny -- deb50) In this case, binary only uploads sort below security uploads, but NMU's sort above security uploads. This solves the use case: - The package version is 1.3 in all distributions. - A security issue is found. - 1.3+deb50 is uploaded to stable and testing. - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable. - Some time passes, and the package is about to migrate to testing. - Migration works, because 1.3+nmu1 1.3+deb50. Using just code names is bad becase there is no ordering: a) 1.0-1sarge1 1.0-1etch1. b) 1.0-1etch1 1.0-1lenny1 You can base security uploads on NMUs, so I think you could get +deb50.1 +deb50.1+nmu1 +deb50.2 +deb50.2+nmu1 See: http://thread.gmane.org/gmane.linux.debian.devel.general/126121 for more details for the reasoning behind this proposal. - I hope I have not missed out any common use cases which require special interpretations of version numbers. If this is acceptable, I will start trying to draft wordings for policy to clarify this area. manoj -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30.4-anzu (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.3 utilities to manage online documen -- no debconf information -- Irrationality is the square root of all evil Douglas Hofstadter Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Aug 18 2009, Don Armstrong wrote: On Tue, 18 Aug 2009, Manoj Srivastava wrote: Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file (1) is not necessarily true in the case of NMUs of native packages.[1] The only way to tell if a package is native or not is to inspect the .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, it should be a big deal.] I understand today that perhaps NMU's of native packages do not follow 1. However, consider this: 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led to developers reference changing its recommendation. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 That link states that debhelper, cdbs, and (ahem) my scripts all use the same convention for distinguishing native packages from non native ones, namely, the presence of a hyphen in the version number. I am suggesting, in this case, we *make* policy to explicitly adopt the design that the dev-ref, devscripts, lintian, etc all currently espouse; with perhaps the proviso that this be a should or perhaps recommended bahaviour for a while. I consider having to look into a .dsc file to see whether a package is a native NMU or a non-native package to be a flaw large enough to warrant making policy here, especially since debhelper and cdbs and devscripts all follow this. As far as policy is concerned, there is a strong indication that if there is a - in the version, there is an upstream package, and there is a debian revision, and there are also indications that a non-native package needs to have orig.tar.gz/diff.gz. Making a package seem like it is native and non native based on whether the last upload was a NMU is bad, and it contradicts both policy on version number format and the def ref recommendations. That said, the rest looks reasonable, but it would probably be useful to make sure that we're actually representing current practice. Given that devscripts, lintian, debhelper, cdbs and the dev-ref all advocate or implement +nmu\d+, I have tried to do so. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. __ egrep '^Version: ' /var/lib/dpkg/available | wc -l 26797 __ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/ print' | wc -l 2127 Of course, the majority of these packages are not native packages, but it is hard to tell which are which. manoj -- Cynicism is an unpleasant way of saying the truth. Lillian Hellman Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Aug 18 2009, Don Armstrong wrote: On Tue, 18 Aug 2009, Manoj Srivastava wrote: Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file (1) is not necessarily true in the case of NMUs of native packages.[1] The only way to tell if a package is native or not is to inspect the .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, it should be a big deal.] I understand today that perhaps NMU's of native packages do not follow 1. However, consider this: 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led to developers reference changing its recommendation. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 That link states that debhelper, cdbs, and (ahem) my scripts all use the same convention for distinguishing native packages from non native ones, namely, the presence of a hyphen in the version number. I am suggesting, in this case, we *make* policy to explicitly adopt the design that the dev-ref, devscripts, lintian, etc all currently espouse; with perhaps the proviso that this be a should or perhaps recommended bahaviour for a while. I consider having to look into a .dsc file to see whether a package is a native NMU or a non-native package to be a flaw large enough to warrant making policy here, especially since debhelper and cdbs and devscripts all follow this. As far as policy is concerned, there is a strong indication that if there is a - in the version, there is an upstream package, and there is a debian revision, and there are also indications that a non-native package needs to have orig.tar.gz/diff.gz. Making a package seem like it is native and non native based on whether the last upload was a NMU is bad, and it contradicts both policy on version number format and the def ref recommendations. That said, the rest looks reasonable, but it would probably be useful to make sure that we're actually representing current practice. Given that devscripts, lintian, and the dev-ref all advocate or implement +nmu\d+, and that debhelper and cdbs look at the hyphen for determining native vs non-native, I have tried to do so. I think the proposed practice is strictly better than not specifying any conventions, and where possible, Ihave tried to stick to best practices as documented in the dev-ref to base policy on. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. __ egrep '^Version: ' /var/lib/dpkg/available | wc -l 26797 __ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/ print' | wc -l 2127 Of course, the majority of these packages are not native packages, but it is hard to tell which are which. manoj -- Cynicism is an unpleasant way of saying the truth. Lillian Hellman Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Josselin Mouette wrote: Hi, the question in the subject may sound a bit naive, but I’m starting to wonder why we still set the Standards-Version in package control files. AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This is no way implies that the package with an old standards version does not have to comply to latest policy. In other words, I can't just set Standards-Version to 0.0.0 and blithely ignore any policy -- the package would be buggy if it does not follow the latest policy, regardless of the standards version. However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. Currently I don’t think this header reflects anything useful in a vast majority of our packages. I’m spending more time updating the header than actually updating old packages to conform to policy changes. What would you think of deprecating this header? This would be bad, since when someone looks at the package, they would not know easily what they have to look for to update the package. The Standards Version gives a pointer into the upgrading checklist, and that remains useful. manoj -- Insufficient facts always invite danger. Spock, Space Seed, stardate 3141.9 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Neil Williams wrote: On Wed, 12 Aug 2009 11:59:09 +0200 Josselin Mouette j...@debian.org wrote: However I think this approach doesn’t fit the current way we deal with policy changes. The de facto way of dealing with policy breakages currently is to directly report serious bugs against packages not conforming, regardless of the Standards-Version they declare. We will even often NMU them without changing the Standards-Version, while having actually fixed them to conform to newer versions. In many cases, wouldn't such a relationship be better expressed by a dependency on a package that implemented the new behaviour? Often it's dpkg and many of those situations are already handled via just such a dependency. So why have the extra field? Because not all new policy changes are reflected by a new version of some package? And for Developer picking up a package and wanting to know what needs to be looked at in order to achieve policy compliance, a mess of possible dependency relationships is a lot harder to base that decision on than a simple standards version. Also, for Standards-Version: to be useful again, wouldn't it be appropriate for lintian to have support for testing the package against the *declared* standards version? I doubt that this would be particularly welcome or easy to implement, hence I agree that the field itself is becoming irrelevant. Yes, we can test with the version of That would be wrong. A Standards version has nothing to do with deciding whether or not a package is buggy WRT policy. If it does not match current policy, the package is buggy, period. Even if the mainteiner has cleverly set the standards version to 0.0.0. The standards version is not a means of getting out of meeting policy. From a Project point of view, it is useful to see if a package in the archive meets current policy, not whether it met policy when the standards version was last touched (and encourage people to not change the standards version or follow policy). So assuming there is a relation between bugginess and standards version is wrong; the latter is only useful for people trying to update the package, so that they know what to look for. manoj -- Some of my readers ask me what a Serial Port is. The answer is: I don't know.Is it some kind of wine you have with breakfast? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
On Wed, Aug 12 2009, Josselin Mouette wrote: Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit : AIUI, this header is here to indicate which version of the policy the package is supposed to conform to. This way, we have a way to enforce which policy versions are supported, e.g. in a stable release, by forbidding the too old versions. No, that is wrong. The reason we put in the Standards version is to let the next developer know what to look for in the upgrading checklist in policy in order to bring the package up to date with policy This assumes that the previous developer has correctly updated the package according to the stated Standards version. Which is, in the general case, wrong. Firstly, when you update a package, the previous maintainer could have done all kinds of things wrong. If you do not trust the maintainer, you check. The chances are that they did not update the standards version, so youhave more checking to do from upgrading checklist. More work for you, but no other downside. If you think the maintainer was malicious, and updated the standards version without making changes to the package, you are stuck with a full review of policy and the package. And report the maintainer. If you think the majority of the maintainers upo blindly upgrading the standards version and not the package, we need to do some maintainer purging. In my experience, the packages I have worked with, the standards version has not been upgraded without the package itself. This also assumes that the upgrading checklist contains all relevant information, which is also wrong for real cases. Frankly, if you think that upgrading checklist does not contain everything relevant a maintainer has to check for the policy update in question, this is a bug, and I do not se that you have filed any. And can you point to a concrete case, please? Which policy upgrade came with a deficient upgrading checklist? If you want to bring a random package up-to-date with the policy, it is generally more useful to look at its RC bugs, and also at its other bugs. Heh. You have a far greater faith in people discovering and filing RC bugs. Lookgin at RC bugs is of course a necessary, but not, in my opinion, a sufficient, condition for bringing the package up to date. If a maintainer are not looking at the standards version, then the packages they maintain are suspect. Said otherwise, with the current state of our practice, the workflow you describe is flawed. Which makes the standards version declaration useless. I beg to differ. The standards version is a useful tool for people who follow the (simple) rules, and just because there are lazy (and perhaps malicious) maintainers out there does not mean the work-flow is broken. I hope that the majority of developers are not as lazy, incompetent, or malicious as you imply, and do not update the standards version without actually updating the packages in question. manoj -- Bachelor: A guy who is footloose and fiancee-free. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote: There will still be a repository with all the .ddebs. And aptitude and dpkg will know how to install ddebs, somehow? and synaptic, etc? But also we will have a share that will ship all the debugging symbols in a build id file hierarchy structure (so something like .build-id/xx/xxx.debug). You can mount it in your system and use it as if you had installed every -ddeb available in the archive. So all debugging has to happen online? Many places have a prohibition against mounting a file system from outside the firewall, though installing packages that have been vetted is permissible . Furthermore, if disk space permits it, we will provide symbols for more than one version (i.e. not only the current package in the archive, but maybe the last three or whatever we can do), since build ids permit it. With packages, mirrored repositories may have a different retention policy, and not rely on the packages one has installed disappearing off the remote filesystem. The system you propose works great for the use case you have envisaged: Debugging on a low security instllation with always on broadband connection to the network; but surely that is not the only model we provide. I am also wondering about the obstacles placed in the path of packages that will not be covered by the automated system. While we were talking about generating .debs, that was some work, but not any different from creating a package. Now, in order to create a hand crafted ddeb, what does one do? Add a nerw package to debian/control, build it, rename the package, edit ./debian/files before dpkg-genchanges is called -- this is more complex than just calling dpkg-buildpackage and be done with it. So I am wondering if the selction by package name is not good enough, and whether we really need selection using *.ddeb$ -- /.*-ddeb_.*\.deb$/ is not that much more complex a regular expression, and it brings with it the ability to manually create the debug symbol packages easily, using dpkg-bvuildpackage. I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. manoj -- Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Russ Allbery wrote: Paul Wise p...@debian.org writes: On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastavasriva...@debian.org wrote: I too am wondering if we should defer the polivy change until the details get shaken out with a partial deployment of the scheme. Full deployment already happened (in Ubuntu). As .ddebs? What's the policy about what can go in them and how are they integrated with the packaging tools? And could you point me at the Ubuntu share for the debugging information so that I can see what protocols it's using? Did ubuntu have to modify the default package manager (synaptic, right?) in order to allow the user to install the ddebs locally? I would be interested in the details of how to hook up to the debug packages archive in Ubuntu (I shall try installing an Ubuntu virtual machine this weekend to try this out). Prior experience is *great*. We can learn from the experiences of Ubuntu. I would also like to learn of the coverage Ubuntu managed to achieve, given that they have full deployment. What is the percentage of packages they managed to auto create? This is indeed very valuable information, I am surprised no one has been mentioning any figures at all about this full deployment in Ubuntu. manoj -- A mind is a terrible thing to have leaking out your ears. The League of Sadistic Telepaths Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Wed, Aug 12 2009, Russ Allbery wrote: Paul Wise p...@debian.org writes: Not having anything to do with Ubuntu, I don't know anything about the details, but they have had automatic debug packages and automated crash report stuff for quite a while, a couple of years IIRC. The specs for that are here: https://launchpad.net/ubuntu/+spec/apt-get-debug-symbols https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports Ah, thank you! https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does use *.ddeb. There isn't any clear statement about how *.ddeb packages differ from *.deb packages. It looks like, by and large, they don't, except they may not need to contain the same set of things. The packages are not in debian/control or the things fed from it, but are in *.changes. Thanks for the link. They mention: --8---cut here---start-8--- # They (ddebs) can be arranged in a proper pool structure with a Packages file etc., so that existing tools to mirror, download, and ship debs can be reused. # Users can actually install them if they want to. ... An apt frontend will be provided to conveniently install debug symbols: e. g. apt-get debug apache2 would install the -dbgsym ddebs for apache2 and all its dependencies. This will allow developers to actually install the .ddebs --8---cut here---end---8--- This is what I find interesting. So, not quite aptitude/synhaptic, but analogous to apt-get source. This does answer some of the questions I had about implementation. Ubuntu is creating one debug package per binary package, as I and a few other people have said we prefer. However, they're using the gnu_debuglink method, not the id method, so they don't have the one problem with that method previously identified in this thread when the same binary is copied into multiple packages. Or the facility to keep debug symbols around for multiple versions of shared libraries (with the same soname), which is an advantage the build id method has. The proposal appears to only work for packages using debhelper, although the steps are laid out so presumably they could be done manually if need be. Yes, though some sleight of hand might be needed do build a package which is not in control (dpkg-deb --nocheck), or if the package is in debian/control, debian/files would have to have the .deb line removed, and dpkg-distaddfile used to register the ddeb file name). Ubuntu uses -dbgsym as the magic namespace. I don't know if it would be good for us to do the same or to use a different namespace to avoid problems for them in cases where we decide to build the package manually via debian/control and debian/rules. I would still like to see coverage figures to figure out what percentage of the archive will need this. It looks like the plan with *.ddeb is to treat them specially in the archive software and divert them into a different tree in the archive instead of using a separate archive area, which I think they're doing now from that page. It also looks like one of the justifications for the separate package is to hide them in the apt front-end so that users don't see all the additional packages. I'm personally skeptical this is a good idea, although I can see the merits of not returning them in apt-cache search. I am not sure I see that. When I ask apt cache for packages that currently have a debug package, I do not see the rpesence of information about the debug package as garbage; it is nice to know that the debg information exists. Ah, and it looks like the automated crash reporting offers to download the -dbgsym packages and install them. Reading the spec, it seems to me that the primary motivation was for users to provide crash dumps with bug reports, and not much screen time is given to users debugging their own applications linked to vendor libraries, or for the developer user in general. I think that use case should be addressed as well. I don't see any sign in this of a share. I am not sure I see much utility in a share, personally, since I have not really had an installation where I spent any time in where the mount would not have been prevented by perimeter defenses and security policies. manoj -- Help save the world! --Larry Wall in README Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Sune Vuorela wrote: On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote: On Mon, Aug 10 2009, Sune Vuorela wrote: On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote: I would also add that the debug symbols should live in /usr/lib/debug/ . /full/path/to/lib_or_binary, blessing the current practice. You are missing the new features of build-id as written earlier by insisting on this. Hmm. I see very little benefit here. Firstly, to use build id, you have to intercept the upstream build system and add --build-id (and perhaps the --build-id-style) option to ld, instead of the current method of letting the upstream build happen and working on the produced objects -- this is more intrusive. And what do we gain? * For the build ID method, GDB looks in the `.build-id' subdirectory of the global debug directory for a file named `NN/.debug', where NN are the first 2 hex characters of the build ID bit string, and are the rest of the bit string. (Real build ID strings are 32 or more hex characters, not 10.) So, we would still need to create /usr/lib/debug/ . /full/path/to/lib_or_binary/ in either case, and instead of the lib-or-exec name, create NN/.debug file there (which is non human readable, really). What have we gained? There is no potential for file name conflicts, since if there are file name conflicts in the debug symbol files, there would be file name conflicts in the corresponding packages, which is already a bug in Debian. I see added complexity with no real benefit for us: it might have value in an environment where file conflicts are not verboten. manoj -- An apology for the devil: it must be remembered that we have heard only one side of the case. God has written all the books. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Sune Vuorela wrote: On 2009-08-11, Manoj Srivastava sriva...@debian.org wrote: Hmm. I see very little benefit here. Firstly, to use build id, you have to intercept the upstream build system and add --build-id (and perhaps the --build-id-style) option to ld, instead of the current method of letting the upstream build happen and working on the produced objects -- this is more intrusive. And what do we gain? The plan is to make --build-id the default (As it is on many other distributions). * For the build ID method, GDB looks in the `.build-id' subdirectory of the global debug directory for a file named `NN/.debug', where NN are the first 2 hex characters of the build ID bit string, and are the rest of the bit string. (Real build ID strings are 32 or more hex characters, not 10.) So, we would still need to create /usr/lib/debug/ . /full/path/to/lib_or_binary/ in either case, and instead of the no. it would be /usr/lib/debug/.build-id/NN/NN.debug Right. Mostly human unreadable. lib-or-exec name, create NN/.debug file there (which is non human readable, really). What have we gained? There is no potential for file name conflicts, since if there are file name conflicts in the debug symbol files, there would be file name conflicts in the corresponding packages, which is already a bug in Debian. I see added complexity with no real benefit for us: it might have value in an environment where file conflicts are not verboten. And the next step is to provide /usr/lib/debug/.build-id exported from some internet service so that you download debugging symbols on demand, for example thru drkonqi or bug-buddy or maybe directly with gdb. You can just export /usr/lib/debug/ from the central service equally easily, no difference there -- you can just provide the current Sid/testing/stable snapshot. Having a reliable way of getting from a random library version and random executable version to get the exact corresponding debug symbols, the build-id method is just much more reliable. Except you have not indicated how you (or debhelper) is going to intercept ld to add the requisite arguments. manoj -- Murray's Rule: Any country with democratic in the title isn't. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Josselin Mouette wrote: Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit : Hmm. I see very little benefit here. Firstly, to use build id, you have to intercept the upstream build system and add --build-id (and perhaps the --build-id-style) option to ld, instead of the current method of letting the upstream build happen and working on the produced objects -- this is more intrusive. And what do we gain? Without build IDs, GDB has no sure way to map the binary to the correct detached symbols. Therefore it will read the whole file to compute its CRC32 (!) and compare it to the one stored in the gnu_debuglink section of the binary. This sole issue is responsible for gdb taking up to several minutes to produce a backtrace for binaries using big libraries like xulrunner. And don’t even think of using the debugging symbols over the network in this case. Yes, that would indeed be silly -- if you have managed to intercept ld and added --build-id to the executable, it would be silly not to have the file in the location gdb will look in. However, if you do not use the build-id mechanism, and use what we currently use in dh_strip and friends, objcopy --add-gnu-debuglink adds information that gdb looks at to figure out where the debug symbols live -- and no CRC check sum is ever performed. So a mixed mode approach would indeed be bad. But a pure debug link method does not have these stated drawbacks. Given the difficulty in intercepting ld commands in upstream build systems, I would be inclined to just standardize the debug link method, given that it produces human readable file names (so I can determine manually if I have debugging symbols for some library or not) as an added bonus. manoj -- Work is the crab grass in the lawn of life. Schulz Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Josselin Mouette wrote: Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit : Except you have not indicated how you (or debhelper) is going to intercept ld to add the requisite arguments. http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html So the proposal is to add --enable-linker-build-id to CFLAGS? OK, I guess that would work. But you still have the advantage, using the current debug link mechanism, of looking to see if you have debug symbols for a given executable/library easily, without having to compute potentially 3 checksums (depending on which algorithm was selected at build time) and trying to match that (in multiple directories). Can you point ot me the disadvantage of continuing to use what dh_strip does now? manoj -- I have the simplest tastes. I am always satisfied with the best. Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
Hi,
All right. Having been educated about the new build-id
mechanism, I think there is not reason for policy to prohibit either
approach, or to settle on one or the other.
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
packages names may end in ${debug suffix}.
2) These packages may just symlink
/usr/share/doc/${package name}-${debug suffix} to
/usr/share/doc/${package name}
(and of course, depend on ${package name}
3) The detached debugging symbols should be placed in a subdirectory of
/usr/lib/debug, the exact path being determined by the mechanism
used (either build ids or debug links can and may be used)
4) Otherwise, these packages are normal debian packages
The ${debug suffix} nay be ddeb, or something else to be
decided.
Comments?
manoj
--
Well, it's hard for a mere man to believe that woman doesn't have equal
rights. Dwight D. Eisenhower
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: OK, I guess that would work. But you still have the advantage, using the current debug link mechanism, of looking to see if you have debug symbols for a given executable/library easily, without having to compute potentially 3 checksums (depending on which algorithm was selected at build time) and trying to match that (in multiple directories). If you have the .ddeb package installed, you will have the debugging symbols installed :) I guess that is true. Figure out which package the executable belongs to, check to see that the -ddeb package exists. Can you point ot me the disadvantage of continuing to use what dh_strip does now? It can still be used, but you will miss the advantages of using build ids. I guess I was trying to ask what the advantages were, apart from the CRC check overhead that is skipped on load. I presume that the crc check sum has been demonstrated to be onerous. Are there any other advantages I am missing? manoj -- innovate, v.: To annoy people. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Russ Allbery wrote:
Emilio Pozuelo Monfort poch...@gmail.com writes:
Manoj Srivastava wrote:
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
packages names may end in ${debug suffix}.
They may be automatically created. They may also be manually created (if
they are listed in debian/control, so for complex packages where they
need some manual work, it can be done).
Whether they're automatically or manually created is irrelevant for Debian
Policy. Policy describes what the output should be, not what tools one
uses to get there.
I think the relevant question for Policy is whether these packages will be
listed in debian/control in the source package, in Binary in the *.dsc
file, and in Binary/Files/Checksums-* in the *.changes file. And I don't
know the answer to those three questions from the discussion so far.
Here is my take on this:
a) helper packages may be extended to created debug packages by
default, whether or not they're mentioned in control. This means
that any package rebuilt the next time will get debugging packages,
even if the maintainer takes no action. Policy should not prevent
this use case, so requiring that the control file mentions them
should not be done.
b) Some upstream packages, even if helper packages are used, might not
be readily amenable to automated generation of debug packages, and
manual help might be required. In this category I would also like to
throw in packages that do not use helper packages; since themanual
crafting of debug symbol packages is a commonality. These packages
have the debug packages in debian/control, and htey are built
normally (either through custoim scripts, or helper packages). In
this case, the helper should not automatically generate debug symbol
packages; and thus give us a mechanism to over ride, on a package by
package basis, the creation of automated debug packages.
So I think at this point it is premature for policy to decide
one way or the other about debug symbol packages being mentioned in the
control file (and dsc and changes).
I am also of the belief that perhaps the dsc and the changes
file should treat them like normal .debs; and the differentiation occur
at the archive level, when archive scripts try to determine where these
packages go.
Another reason is that we should not be accepting any packages,
even debug packages, in the archive unless we have a check sum match in
a cryptographically signed file anyway.
manoj
--
Ten years of experience should add up to more than one year's experience
multiplied by ten.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Tue, Aug 11 2009, Russ Allbery wrote: Josselin Mouette j...@debian.org writes: Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit : * What about contrib and non-free packages? Do they just lose here? How about yes? I'm okay with that as an answer. I just want to document it if so. So policy is going to prohibit contrib or non-free packages with debugging symbols (or, at least, debug packages that may use the common nomenclature)? This seems kinda drastic. So the packages with debug symbols from those sources will continue to live in the primary archive, and not go into the specialized debug area, If we use build IDs (and this has quite some advantages, like being able to do more than just dump the ddebs on a repository), this can lead to having the same detached debugging symbols in two binary packages, since sometimes a binary is built twice the same exact way and put in two different binary packages. Hm, really? The toolchains that I'm familiar with basically never produce the same binary twice; something is always slightly different from timestamp information. Could you give an example of such a case in the archive right now where identical binaries are in multiple packages so that I can better understand how this happens? The only way this can arise is if you build once, and copy the same files into two conflicting packages. Silly, but nothing in policvy prohibits it as long as the packages either conflict or put the files in different locations. The consensus on #debian-dak when we discussed this specific issue was to use one ddeb for each source package by default, and to let the door open to the maintainer overriding this default with several ddebs in a source, using a new header in the control file. This way we can keep things as simple as possible, without losing the possibility to handle corner cases that will arise. In this case, I believe that, in order to comply with some of our DFSG-free licenses, we will have to ship a copyright file in the debug package. Also, some source packages are *huge*, and I don't want to have to install 50GB of debugging information for, say, all of KDE just because I want the debugging symbols for a single library. I suppose that's why you have the escape clause of letting maintainers do it differently if they desire, but there I really would like to see us treat the entire archive identically if at all possible. Personally, I think that one debug package per binary package makes more sense, and the optimization for duplicate files in multiple packages is likely to be too small to be worth considering; and we can have the header revert the decision: one debug file/binary, unless the user specifies that theres should be one giant debug package (and I am not sure how many packages will need to do this because they ship duplicates anyway. manoj -- Leibowitz's Rule: When hammering a nail, you will never hit your finger if you hold the hammer with both hands. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Steve Langasek wrote: On Sun, Aug 09, 2009 at 05:42:04PM -0700, Russ Allbery wrote: I don't have a strong opinion on whether ddebs should be documented in policy, but I certainly don't agree with requiring dpkg to understand them as a prerequisite for implementing a general purpose, public archive for auto-stripped debugging symbols packages. There really is no reason for dpkg to treat these packages specially - a simple namespace convention imposed by Policy (i.e., reserving package names ending in -ddeb for use by this archive, which is what has been proposed) is sufficient, and requires no changes to dpkg, which is as it should be. Or even just -dbg, since aren't the existing debug packages basically .ddebs, modulo bugs? There are a few significant exceptions, such as libc6-dbg and libqt4-dbg, where the packages contain complete alternate debug builds of the libraries, /not/ detached debugging symbols. Well, of we are top carve out a namespace in policy, it also makes sense if we define whay such packages ought to contain as well. Having a namespace carved out for packages with only detached debugging symbols (and with the normal policy rules on regular packages -- copyright, changelog, etc). manoj -- The wise shepherd never trusts his flock to a smiling wolf. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Steve Langasek wrote: On Sun, Aug 09, 2009 at 07:37:10PM -0500, Manoj Srivastava wrote: dpkg doesn't know about filenames AFAICS. So you can't coinstall foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the -ddeb suffix. If we are going to enshrine ddebs into policy, we might as well teach dpkg about ddebs. I don't have a strong opinion on whether ddebs should be documented in policy, but I certainly don't agree with requiring dpkg to understand them as a prerequisite for implementing a general purpose, public archive for auto-stripped debugging symbols packages. There really is Since this is on -policy, I am commenting on when it gains enough gravitas to be enshrined in policy. Getting things in policy is also not a pre-requisite for implementing a general purpose, public archive for auto-stripped debugging symbols packages. There is a namespace issue here, that falls in scope for Policy because it impacts interoperability; if there are going to be limits placed on the names of packages in the main archive, that almost certainly *does* belong in Policy. And the Policy editors should not be dictating a dpkg implementation for ddebs as a precondition, not when that dpkg implementation isn't required and doesn't appear to have any backing from the dpkg maintainers. The policy editors may ask for the design to be implemented and tested, and (gasp) even critique the design, before having it added to policy. Policy is not the place to shoce in untested/raw design. And in this case, there seems to be an issue of occams razor: why should a new file suffix be created when policy based naming wold not require it in the first place; namespace partitioning can be done on the package name, not on the filename. So, please keep heckling from the peanut gallery to a minimum, please, and assume that policy editors have a modicum of sense when dealing with their role duties. I do have a question: Why is the fact that these are automatically created relevant? Because if they're *not* automatically created, there's no namespace issue: package name conflicts would continue to be resolved the usual way, via ftpmasters and the NEW queue. Seems like if policy carves out a namespace for debug packages, it would serve for both automatically generated and hand crafted debug packages; and it is trivial for the automatic generation not to happen when there is an entry in debian/control for a debug package already, as long as there is a naming convention for debug packages. Why should it be a leading change in policy? Can't we try out the experiment, make any changes needed, and then come with the policy change? If we do not need maintainers to change anything, ans we do not need dpkg to change anything, why is there a hurry to get this into policy before it has been implemented and tested? I'm in no particular hurry, myself, but I think the right time to reserve package namespace is *before* there are exceptions in the archive that have to be dealt with. What with the maxim about Policy not making packages insta-buggy, and all. If policy is going to be creating name spaces for debug packages, it should be done on the basis of the content or type of package it is, not because of the tools that created it. We do not have a emacs-debhelper_2.3-1_amd64.deb emacs-cdbs_2.3-1_amd64.deb emacs-yada_2.3-1_amd64.deb So as long as there is clarity on what the contents of the package should be (only detached debug symbols, kept in a standard location, or something), how they are generated should not matter. So why not just have foo-ddeb.*.deb? Why not, indeed? manoj -- Oh what wouldn't I give to be spat at in the face... a prisoner in Life of Brian Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Philipp Kern wrote: Why is it not trivial? I have such a hook in my pakages, and it is not rocket science. If you think that adding stuff like --8---cut here---start-8--- filelib_or_exec_file objcopy --only-keep-debug lib_or_exec_file debug_file objcopy add-gnu-debuglink debug_file lib_or_exec_file strip --remove-section=.comment --remove-section=.note \ --strip-unneeded lib_file strip --remove-section=.comment --remove-section=.note exec_file --8---cut here---end---8--- to a rules file is not at all trivial, then heaven help us. Plus lines to actually create the package with appropriate control info or/and putting it into debian/control which we wanted to avoid (I think). Of course if we then go and try to modify the behaviour slightly (like having build-ids and stuff) we still have to modify all those packages and not just the helper and a binNMU. But I guess I can't argue with you about that anyway. From a policy PoV you're right, we do not impose debhelper upon everyone. I already consider debhelper coverage as a worthy goal. :-P Oh, it is a wonderful goal. But anything we put into policy should not just depend on debhelper being the only route to get the advantage of debug packages; there should be enough information in there where a packager (or developer of a helper package) can create policy compliant debug packages. I have never objected to having debhelper auto-create debug packages, I just object to putting things in policy that say Use debhelper or python-central to create these policy compliant packages. Policy ought to deal with specifying the package naming convention and the contents, not specifying you get whatever the tool shall produce. manoj -- We all know Linux is great...it does infinite loops in 5 seconds. (Linus Torvalds about the superiority of Linux on the Amsterdam Linux Symposium) Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Don Armstrong wrote: On Mon, 10 Aug 2009, Manoj Srivastava wrote: Why is it not trivial? Because it requires editing the rules file for each such package? (debhelper using packages all get tweaked in a single shot.) Rubbish. I suspect all cdbs using packages can be similarly tweaked (or any packages that use my build system). Also, It is indeed trivial to add that to non-helper-package using packages, it just requires some editing (just like modufying helper packages will need editing). I do not find edting a rules file to be non-trivial, so far. (thank the lord for the one true editor). I agree it is very non trivial for debhelper to change packages that do not use it; but that was never something to shoot for. manoj -- The best laid plans of mice and men are usually about equal. Blair Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Don Armstrong wrote: Also, It is indeed trivial to add that to non-helper-package using packages, it just requires some editing (just like modufying helper packages will need editing). Since it's trivial, I look forward to seeing patches from you to implement policy once we decide it on all of the non-debhelper using packages. [How many person-hours of labor are we talking about now?] Why would you see patches? You will see new uploads of my packages. As a DD, I am responsible for my packages, and making sure they follow policy -- and any policy mandate to add debug packages will be fairly trivial to implement (I already have kernel-package allowing debug kernel images to be built). I think it will take me about 30 minutes or so to code, and of course any new packages will have to be built and tested, but I can mostly automate that bit. Turning on debug packages is likely to be less than 5 minutes per package, unless I choose to implement turning on debug packages without entering them in debian/control. Even if I let a helper package build some packages, I would still have to test it -- more so, since it would be mostly black magic. So people who use helper packages will still have to rebuild/test their packages anyway -- I do not see the testing part as a new and onerous burden only upon myself. Or were you imagining some single person is going to test all these debug packages? How many thousands of man hours is that? I would not presume to let gobs of untested packages loose on the archive, no. So anyone not using a helper is already responsible for having their packages follow policy; and if they follow the current policy already, adding debug packages will be trivial. manoj -- I have been insulted! I have been hurt! I have been beaten! I have been robbed! Anger ceases in those who do not harbour this sort of thought. 4 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Roger Leigh wrote: Could we not just use a -ddbg suffix for detached debug information, perhaps with a new archive section to match? This will not conflict with existing practice for -dbg, so could go into Policy without violating any prexisting namespace conventions. Reading through this thread, I don't see a compelling reason for using a .ddeb extension given that they are just regular .debs, nor for keeping the packages separate from the main archive (if the size of the Packages file is an issue, can't they just go in a separate debug section/component?) I would support this. I would also add that the debug symbols should live in /usr/lib/debug/ . /full/path/to/lib_or_binary, blessing the current practice. manoj -- A shortcut is the longest distance between two points. Professor Charles P. Issawi Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Mon, Aug 10 2009, Sune Vuorela wrote: On 2009-08-10, Manoj Srivastava sriva...@debian.org wrote: I would also add that the debug symbols should live in /usr/lib/debug/ . /full/path/to/lib_or_binary, blessing the current practice. You are missing the new features of build-id as written earlier by insisting on this. Please, Do enlighten me. manoj -- I have more hit points that you can possible imagine. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
