Bug#89038: mime policy copying update-mime(8)
On Sun, 03 Apr 2011, Russ Allbery wrote: The bug: http://bugs.debian.org/89038 is still looking for two more seconds. This would allow us to retire the tiny separate mime-policy document. Could other folks take a look and confirm that all looks well? Seconded. It's fine for me. (Note that I pinged the mime-support maintainer which looks like MIA since he has not yet switched to using triggers support while Emilio Pozuelo submitted a patch some time ago. If that gets merged, the policy will have to be updated again.) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404064232.gi21...@rivendell.home.ouaza.com
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Raphael Hertzog wrote: On Sun, 03 Apr 2011, Russ Allbery wrote: My inclination is to second this, but I want to make sure that we've answered your and Julien's objections first. And for complete reference, dpkg accepts those version in /var/lib/dpkg/status (so that dpkg still works for users with affected packages installed) but will not a accept to install a .deb with a bad version anymore. One possibility would be to mandate in policy that: 1. upstream_version must start with a digit; 2. package management tools should accept an upstream_version that does not start with a digit. But that would be somewhat confusing in my opinion, and it might be hard to sell (2) as something that belongs in policy. If there were a separate packaging system manual, life would be easier. Lacking that, I can see the potential value of dpkg validating the packages it installs (though it's painful). -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404072325.GA12489@elie
Bug#89038: mime policy copying update-mime(8)
On Sun, 2011-04-03 at 20:44 -0700, Russ Allbery wrote: The bug: http://bugs.debian.org/89038 is still looking for two more seconds. This would allow us to retire the tiny separate mime-policy document. Could other folks take a look and confirm that all looks well? We separately should really include more documentation of this subsystem, but that can be handled separately and we seem to have gone many years without noticing a serious lack. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Some optional equipment shown. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#620674: base-files: Please include the text of the Open Font License (OFL) in /usr/share/common-licenses
Processing commands for cont...@bugs.debian.org: reassign 620674 debian-policy Bug #620674 [base-files] base-files: Please include the text of the Open Font License (OFL) in /usr/share/common-licenses Bug reassigned from package 'base-files' to 'debian-policy'. Bug No longer marked as found in versions base-files/6.1. thanks Stopping processing here. Please contact me if you need assistance. -- 620674: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620674 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130190955819268.transcr...@bugs.debian.org
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
* Russ Allbery [Sun Apr 03, 2011 at 08:12:03PM -0700]: Michael Prokop m...@debian.org writes: Yeah, actually the change is breaking existing packages which used to work just fine (disclaimer: no, the ones I'm talking about aren't available in the official Debian pool). I understand the change but a timeframe for upgrading would be nice with warnings instead of erroring out. I think this is more an objection to the dpkg change than to the Policy change, correct? ACK Policy doesn't govern out-of-archive packages, and I think it's reasonable to just forbid version numbers starting with a letter in the Debian archive rather than saying should not about something that's syntactical. ACK My inclination is to second this, but I want to make sure that we've answered your and Julien's objections first. Thanks! regards, -mika- signature.asc Description: Digital signature
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
On Mon, Apr 04, 2011 at 02:23:25AM -0500, Jonathan Nieder wrote: Raphael Hertzog wrote: On Sun, 03 Apr 2011, Russ Allbery wrote: My inclination is to second this, but I want to make sure that we've answered your and Julien's objections first. And for complete reference, dpkg accepts those version in /var/lib/dpkg/status (so that dpkg still works for users with affected packages installed) but will not a accept to install a .deb with a bad version anymore. One possibility would be to mandate in policy that: 1. upstream_version must start with a digit; Unfortunately, we cannot force upstream to use a version that start by a digit, We would need to document a mangling process for upstream version that start by a letter. I really fail to see the motivation for this change in dpkg. So far, I am objecting to the change as it is. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
* Bill Allombert [2011-04-04 12:03 +0200]: Unfortunately, we cannot force upstream to use a version that start by a digit, We would need to document a mangling process for upstream version that start by a letter. Quoting policy: | epoch | | This is a single (generally small) unsigned integer. It may be | omitted, in which case zero is assumed. If it is omitted then the | upstream_version may not contain any colons. upstream_version git1234 could be prefixed with epoch 0 and thus lead to the version number 0:git1234-debian_revision. Maybe this could be mentioned in the policy. Regards Carsten -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105943.ga1...@furrball.stateful.de
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Hi, On Mon, 04 Apr 2011, Bill Allombert wrote: 1. upstream_version must start with a digit; Unfortunately, we cannot force upstream to use a version that start by a digit, We would need to document a mangling process for upstream version that start by a letter. We have no upstream with such versions currently in Debian. I don't really see the point of your objection. There's no supplementary work involved in Debian. I doubt we'll ever have to mangle the version name to satisfy the constraint but even if we have to, it's trivial to add a leading 0. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404121326.gd25...@rivendell.home.ouaza.com
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
On Mon, Apr 04, 2011 at 12:59:43PM +0200, Carsten Hey wrote: * Bill Allombert [2011-04-04 12:03 +0200]: Unfortunately, we cannot force upstream to use a version that start by a digit, We would need to document a mangling process for upstream version that start by a letter. Quoting policy: | epoch | | This is a single (generally small) unsigned integer. It may be | omitted, in which case zero is assumed. If it is omitted then the | upstream_version may not contain any colons. upstream_version git1234 could be prefixed with epoch 0 and thus lead to the version number 0:git1234-debian_revision. Maybe this could be mentioned in the policy. This would not be compatible with the proposed change, because epoch is not part of upstream_version, so upstream_version would still start with a letter. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404124140.GC18503@yellowpig
Processed (with 1 errors): Re: Time for 3.9.2?
Processing commands for cont...@bugs.debian.org: tag 593909 + patch Bug #593909 [debian-policy] clarify the syntax of Debian control files Bug #618013 [debian-policy] clarify the syntax of Debian control files Added tag(s) patch. Added tag(s) patch. tag 609160 + proposal Unknown tag/s: proposal. Recognized are: patch wontfix moreinfo unreproducible fixed potato woody sid help security upstream pending sarge sarge-ignore experimental d-i confirmed ipv6 lfs fixed-in-experimental fixed-upstream l10n etch etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore. Bug #609160 [debian-policy] debian-policy: include DEP5 Requested to add no tags; doing nothing. thanks Stopping processing here. Please contact me if you need assistance. -- 609160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609160 593909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593909 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13019247485198.transcr...@bugs.debian.org
Re: Bug#515837: add Applications/Window Management to menu sub-policy
Le Sun, Apr 03, 2011 at 08:42:08PM -0700, Russ Allbery a écrit : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515837 Hello everybody, this comment will perhaps not help the bug to be closed, but I note that in the case of alltray, the upstream desktop file uses the category “Application;Utility”. Perhaps it would be useful to follow their way ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404142322.gd22...@merveille.plessy.net
Bug#620674: base-files: Please include the text of the Open Font License (OFL) in /usr/share/common-licenses
Santiago Vila sanv...@unex.es writes: On Sun, 3 Apr 2011, Christian Perrier wrote: The Open Font License is quite universally considered as meeting the DFSG. Indeed, several font packages in Debian main provide fonts distributed under that license. Having the full text of OFL distributed in /usr/share/common-licenses would avoid including the text of the license in these packages. According to base-files FAQ, I do not decide about this. The debian policy group does. Hence the reassign. Hi Christian, I did a scan of the archive last year (in June), and the result was relatively few uses of the SIL Open Font License: SIL OFL 1.0 12 SIL OFL 1.1 55 so a total of 67 usages of the family. For comparison, the smallest number of usages of a family of licenses of those in common-licenses is the GFDL, at 875. At the time, we therefore decided that this was some distance away from being widely used enough to put in common-licenses, given the various drawbacks of that (adding a level of indirection for people reviewing licenses and so on). Do you think this may have changed in the subsequent nine months? I can run my survey script again. If you're curious, here's the complete results of my scan from last June: Apache 2.0 1119 Artistic 2285 Artistic 2.0 30 BSD (common-licenses) 1556 CC-BY 3.052 CC-BY-SA 3.0 79 CDDL190 CeCILL 12 CeCILL-B 7 CeCILL-C 20 GFDL (any) 875 GFDL (symlink) 389 GFDL 1.2499 GFDL 1.3 67 GPL (any) 19893 GPL (symlink) 10116 GPL 1 1540 GPL 2 9073 GPL 3 2797 LGPL (any) 7183 LGPL (symlink) 2524 LGPL 2 4679 LGPL 2.1 3189 LGPL 3 691 LaTeX PPL 1.3c 297 MPL 1.1 654 SIL OFL 1.0 12 SIL OFL 1.1 55 Total number of packages: 29470 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqp1syk8@windlord.stanford.edu
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: it's trivial to add a leading 0. We could recommend that explicitly if it would help. It would be my recommendation even without the restriction on version numbers, since alphanumerics would sort after any numbers, so you'd need an epoch otherwise if upstream ever switched to more conventional versions. Yes, that sounds good to me. The remaining open question is how to deal with historical packages. I personally would be happier if dpkg and higher-level tools did not introduce incompatibilities with the historical format when it's easy not to, since being able to install old packages to bisect an old bug is very useful. But I realize I might be in the minority. (For example, old versions of badlands have version numbers starting with build.) I am sympathetic to Guillem's view, which (if I understand correctly) is that dpkg output is unfortunately trusted by some other programs and that not preventing installation of packages with syntax problems would in the long term create a buggy and unstable system. Hopefully he will chime in some time to explain whether the above concern about using the packaging system with historical packages can be reconciled with that (hint: I think so, and I think policy can help). -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404182945.GB25580@elie
Bug#620870: debian-policy: Please add /run as FHS exception
Package: debian-policy Version: 3.9.1.0 Severity: normal Hi, Please could you add /run as an exception to the FHS? I've attached a patch with proposed text. References: #620191 - initscripts support for /run #620157 - base-files provides /run http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 - Fedora adoption http://bugs.freestandards.org/show_bug.cgi?id=718 - FHS proposal Summary: /run is the new home for the contents of /var/run /run/lock is the new home for the contents of /var/lock This is something we've wanted in Debian for many years, which resulted in the compromise of creating /lib/init/rw. However, Fedora, SuSE, Ubuntu and ourselves have proposed to create /run as a temporary filesystem available from early boot to replace /lib/init/rw, /var/run and /var/lock. The above bugs are the Debian implementation. In the attached patch I have documented /run as an FHS exception along with a brief rationale in the footnote, and also updated the notes for init scripts to reflect the change. Note that I've put the change in present (rather than future) tense because this is already adopted by other distributions, and the above bugs should mean it will be adopted in Debian very soon as well. If you would prefer to delay adding this until we actually have this working in unstable, that's fine. I just wanted to make sure that the change is documented correctly. Many thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=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.10.1 utilities to manage online documen -- no debconf information diff --git a/policy.sgml b/policy.sgml index ec605c6..2fda857 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6205,10 +6205,21 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ 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 + additionally allowed: file/run/file, + file/sys/file and file/selinux/file. + footnoteThe file/run/file directory is a + replacement for file/var/run/file, and its + subdirectory file/run/lock/file is a replacement for + file/var/lock/file. These changes have been + adopted by most distributions and have been proposed + for inclusion in a future revision of the FHS. Both + are expected to be temporary filesystems, whose + purpose is storage of ephemeral system state which + should not be preserved across reboot. + The file/sys/file and file/selinux/file + directories are used as mount points to mount + virtual filesystems to get access to kernel + information./footnote /p /item item @@ -6719,14 +6730,18 @@ test -f varprogram-executed-later-in-script/var || exit 0 /p p - file/var/run/file and file/var/lock/file may be mounted - as temporary filesystemsfootnote - For example, using the ttRAMRUN/tt and ttRAMLOCK/tt - options in file/etc/default/rcS/file. - /footnote, so the fileinit.d/file scripts must handle this - correctly. This will typically amount to creating any required - subdirectories dynamically when the fileinit.d/file script - is run, rather than including them in the package and relying on + file/var/run/file and file/var/lock/file should be + symlinks to file/run/file and file/run/lock/file, + respectively, which are temporary filesystems whose + contents are not preserved across reboots. This + arrangement may also be satisfied through equivalent + means, for example bind or nullfs mounts. Because the + presence of files or directories in any of these + directories is not guaranteed, fileinit.d/file scripts + must handle this correctly. This will typically amount to + creating any required subdirectories dynamically when + the fileinit.d/file script is run, rather than + including them in the package and relying on prgndpkg/prgn to create them. /p /sect1
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Russ Allbery wrote: I think this is an interesting conversation, but so far as I can tell it's not particularly relevant to Policy. There are no such packages with those version numbers currently in Debian, so Policy can simply say that there will never be in the future either and be done with it. There is a remaining issue for out-of-archive packages, but I think that's between maintainers of those packages and the dpkg maintainers about what dpkg may support beyond what Debian requires. What about previously-in-archive packages? And what about higher-level packaging tools --- what document describes their contract with dpkg[1]? It is relevant to policy because the proposed change in policy and its implementation would have fallout. It is worth considering whether policy can do something to mitigate that, or at least whether there is _some_ avenue in the Debian project to prevent this damage. Jonathan [1] Perhaps that contract can be informal. It was not my impression that that was the direction Guillem wants to go in (hence the dpkg bug that sprouted this report in the first place) but I could easily be wrong. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404195504.GA32083@elie
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Jonathan Nieder jrnie...@gmail.com writes: What about previously-in-archive packages? Are there any of significance? The example you gave in your previous mail doesn't appear in the BTS at all, so I assume it's quite old if it was ever in the archive. Raphael said that dpkg wouldn't break already-installed packages. Policy primarily applies to packages going forward, plus to references to those packages in versioned dependencies and the like. And what about higher-level packaging tools --- what document describes their contract with dpkg[1]? I don't know that we have one at the moment; regardless, it's not Policy. It is relevant to policy because the proposed change in policy and its implementation would have fallout. It is worth considering whether policy can do something to mitigate that, or at least whether there is _some_ avenue in the Debian project to prevent this damage. Your primary concern is having existing packages stop working because tools drop support for version numbers that they currently support? Would adding a non-normative footnote to that effect help? Something like: In previous versions of Policy, upstream version numbers beginning with alphabetic characters were allowed but discouraged (a should not instead of a must not). There may, therefore, be older Debian packages with upstream versions starting with an alphabetic character. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o6drdfv@windlord.stanford.edu
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: What about previously-in-archive packages? Are there any of significance? I don't know. The example I gave was from a dpkg bug report, and I don't know if it was contrived or not (one would have to ask the submitter). I admit that the principle that dpkg can introduce and is introducing many parsing regressions with policy as its justification is more important to me than this particular example. A reasonable justification for the policy _and_ dpkg change would be allowing this is too much trouble, and almost no packages took advantage of it, so let's disallow it and simplify life for everyone. So please don't take my comments here as a strong objection. ... if it was ever in the archive. One can check at snapshot.debian.org. And what about higher-level packaging tools --- what document describes their contract with dpkg[1]? I don't know that we have one at the moment; regardless, it's not Policy. In practice, Policy is being used that way. I agree that that is not really a good thing. It is relevant to policy because the proposed change in policy and its implementation would have fallout. It is worth considering whether policy can do something to mitigate that, or at least whether there is _some_ avenue in the Debian project to prevent this damage. Your primary concern is having existing packages stop working because tools drop support for version numbers that they currently support? Would adding a non-normative footnote to that effect help? Something like: In previous versions of Policy, upstream version numbers beginning with alphabetic characters were allowed but discouraged (a should not instead of a must not). There may, therefore, be older Debian packages with upstream versions starting with an alphabetic character. Personally, my primary concern is (as mentioned before) that dpkg still be usable for testing old packages. If Policy is not where the packaging system is documented, I don't think a footnote is needed or would be helpful. What would be useful is a consensus that (for example) various tools working with version numbers should accept versions starting with an alphabetic character. An alternative would be a consensus that tools working with version numbers should still behave reasonably [for some definition of reasonable] when given an invalid one, so dpkg could be permissive as it pleases. Otherwise, the situation is kind of unfortunate. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404202716.GD32083@elie
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: What about previously-in-archive packages? Are there any of significance? Ah, I forgot to say: I think changing this to a must with advice to add a 0 when the upstream version does not start with a number would be a good change. Based on your clarifications, I don't think there's anything left to do after that. Packaging system policy for ancient and otherwise noncompliant packages can be left to the packaging system maintainers. Sorry for the confusion. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404204153.GF32083@elie
Bug#620566: dpkg: version number does not start with digit is in contrast to policy
On Mon, 04 Apr 2011 12:40:01 -0700, Russ Allbery wrote:
I think this is an interesting conversation, but so far as I can tell it's
not particularly relevant to Policy. There are no such packages with
those version numbers currently in Debian, so Policy can simply say that
there will never be in the future either and be done with it.
There is (or better: was) cnews, in etch and lenny, with
cr.g7-40.{1,4}.
I noticed this because of
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line
699262 package 'cnews':
error in Version string 'cr.g7-40.4': version number does not start with
digit
each time I build a package (maybe I should just remove oldstable
from my sources.list at some point :))
(Just as a side note, and not relevant for policy.)
Cheers,
gregor
--
.''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe
`-NP: Tom Waits: Innocent When You Dream
signature.asc
Description: Digital signature
