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
Re: 8bit characters in files in Debian packages
On Thu, 2011-03-31 at 15:58 +0200, Bill Allombert wrote: Dear Developpers, there are a small numbers of packages that ship files with non-7bit characters in filenames. $ apt-file search -l -x '[\x80-\xff]' aspell-ca aspell-es aspell-is canorus console-tools dvb-apps ggz-python-games inorwegian jpilot lletters-media otrs2 wnorwegian So this raises two issues: 1) should non-7bit characters in filenames be allowed 2) if yes whould we require the filename to be in a correct UTF-8 encoding ? I raise the question because I was trying to filter out popcon reports that include non-7bit characters since it usually implies corruption of data, but this might not be the case. Also, it seems there is a tool out there that generate .deb packages with names like designkit.702840f10216893fc3494b731e825b33666733d6.1 and filename that are all non-7bit. (probably in Japanese). I think we should definitely *not* forbid this, and we should (at the very least) be working towards supporting the practice. It may be that we can't properly support this until we can guarantee a C.UTF-8 locale as a minimum available standard, but that sounds to me like another justification for such a locale. I think we should encourage the filename to be in a UTF-8 encoding, and even if upstream does use 8-bit filenames with a non-UTF-8 encoding I think that a Debian packager should be encouraged to patch that. I would also be OK with mandating that filenames should only be in either UTF-8 or the ASCII subset thereof, and that ISO-8859-* and other such restricted measures are not welcome on our filesystems. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN If wishes were horses, then beggars would be thieves. signature.asc Description: This is a digitally signed message part
Bug#548867: Proposed patch to update Debian Developer's Duties chapter
On Sun, 2011-03-13 at 10:05 +0100, Lucas Nussbaum wrote: Hi, As one of the (ex-)?dev-ref maintainers, I was also asked to comment by Raphael. Generally, I think that the patch goes in the right direction. I'd like to suggest changes to the last paragraph, though: Lack of attention to RC bugs is often interpreted by the QA team as a sign that the maintainer has disappeared without properly orphaning his package. -Don't be surprised if the MIA team enters in action and ends up orphaning -your packages (see xref linkend=mia-qa /). But you should really avoid -that situation in the first place and ensure that your packages get the attention -that they deserve. +The MIA team might enter in action, which could end up in your packages being +orphaned (see xref linkend=mia-qa /). (I find the last sentence useless as is.) The phrase enter in action sounds really weird. Is it supposed to mean something like also get involved, so perhaps more correct wording might be: +The MIA team might also get involved, which could result in your +packages being orphaned (see xref linkend=mia-qa /). Also, is it true that the MIA team would orphan all of your packages in this case, or just the one that had the unattended RC bug? If it would just be the one then we should say that. Regards, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I like being single. I'm always there when I need me. -- Art Leo signature.asc Description: This is a digitally signed message part
Bug#604990: clarify man page dates policy
On Thu, 2010-11-25 at 22:29 -0800, Russ Allbery wrote: jida...@jidanni.org writes: RA == Russ Allbery r...@debian.org writes: RA No, I don't believe that it should. I don't think this is something that RA we need to make technical Policy about. RA I'll leave this bug open for a bit before closing in case someone else RA disagrees. Well then please add in the manual that Debian officially has no opinion on dates on the man pages, and one is free to do as one feels fit on the matter. I don't see the need for Policy to say anything about this, personally. This seems rather cosmetic to be addressed in Policy. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Unnamed Law: If it happens, it must be possible. signature.asc Description: This is a digitally signed message part
Bug#593611: Clarify whose signature should go in debian/changelog (4.4)
On Sat, 2010-09-18 at 21:10 -0700, Russ Allbery wrote: Okay, here's new proposed wording that incorporates some of the discussion on this bug along with my personal opinion on the best wording. How does this look to everyone? diff --git a/policy.sgml b/policy.sgml index 642f672..314d5d0 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1688,11 +1688,14 @@ p The maintainer name and email address used in the changelog - should be the details of the person uploading emthis/em - version. They are emnot/em necessarily those of the - usual package maintainer.footnote - If the developer uploading the package is not one of the usual - maintainers of the package (as listed in + should be the details of the person who prepared this release of + the package. They are emnot/em necessarily those of the + uploader or usual package maintainer.footnote + In the case of a sponsored upload, the uploader signs the + files, but the changelog maintainer name and address are those + of the person who prepared this release. If the preparer of + the release is not one of the usual maintainers of the package + (as listed in the qref id=f-MaintainerttMaintainer/tt/qref or qref id=f-UploadersttUploaders/tt/qref control fields of the package), the first line of the changelog is Seconded. And I don't understand Ben's objection, since I think you've nicely *avoided* using the word 'sign' in the sense of being recorded in the changelog entry. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN The truth about a woman often lasts longer than the woman is true. signature.asc Description: This is a digitally signed message part
Bug#588014: Documenting the DM-Upload-Allowed field.
On Sat, 2010-09-11 at 23:47 +0900, Charles Plessy wrote: Le Sat, Sep 11, 2010 at 04:15:15PM +0200, Emilio Pozuelo Monfort a écrit : Capitalization is inconsistent across the patch. I guess you should fix that. Ooops (correction attached). I support the change, with the correction. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN To communicate is the beginning of understanding. -- ATT -- 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/1284246206.18652.149.ca...@dave.home.mcmillan.net.nz
Bug#595652: db packages failing to install...
On Sun, 2010-09-05 at 18:58 -0700, Russ Allbery wrote: Holger Levsen hol...@layer-acht.org writes: please clarify what the right behaviour should be and how failing to install without a local db should be treated. Thanks. I agree with jcristau; I think it's reasonable to have database servers be in Recommends, to have postinst prompt for what database to use, and if one choses a remote database that doesn't exist or if one has no database to choose, to have the package configuration fail. I don't think that we should *require* that behaviour, though possibly we can encourage it. Multiple server setups tend to be complex and idiosyncratic, and there may be good reasons why someone is configuring the software without access to a working database, such as when preparing a hot spare, for example, which might interact with the production database in interesting ways if it were to connect. In general I think providing an opt out option which does nothing and successfully configures the package is not harmful. While automation i nice, our own imagination can be limited in understanding the full range of possibilities and we should be careful not to over-guess what the user is trying to achieve by choosing such an option. I could probably come up with a long list of reasons why immediate database connectivity might not be available while I'm installing a package. A few that spring to mind are: * I'm on a ship(/island/branch office/mountain/...) and I'm installing this half of the package now, because I'm here and have the opportunity. I'll do the database bit when I get back to the office next week. * It's 4:35am and the earthquake just wiped out one of our server rooms. I'm trying to get this software running on some equipment in another city and fortunately I *do* have a backup of the configuration files which I plan to apply after installation. * This software is generally configured to run against PostgreSQL, but our organisation insists on running it against $EXPENSIVEDB, which it also supports, but which requires some special magic in the config. And so on. It's definitely worth talking about if the draft database policy says something else, as it appears to. My rationale is that the package setup may simply require a database; some packages don't have a meaningful stand-alone installation with no database support. I think it makes more sense to fail the configure step than it does to require that the user run dpkg --reconfigure later to re-run the package setup. Heh. Shouldn't that be dpkg-reconfigure :-) I know I'd be happier to know that the software was on there, and that if necessary I could run dpkg-reconfigure to use the 'standard' configuration method, but also to know that I had a way of opting out of that, and providing some kind of manual configuration. For those situations requiring more imaginative solutions. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn -- 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/1283773158.17765.69.ca...@dave.home.mcmillan.net.nz
Bug#594658: debian-policy: Add FHS exception for GNU/Hurd directories
On Wed, 2010-09-01 at 17:05 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: I would change the text around a little to add that to the beginning of the paragraph, something like: On GNU/Hurd systems the file/hurd/file and file/servers/file directories are also allowed in the root filesystem. footnoteThese directories are used to store translators and as a set of standard names for mount points respectively./footnote Ordering the words in this way means the reader can decide it's applicability much faster. Perhaps splitting the footnote into two footnotes might help also: ... file/hurd/filefootnoteUsed to store translators./footnote and file/servers/filefootnoteUsed as a set of standard names for mount points./footnote ... Our footnote system is not great, so I'd keep it as one footnote. I agree with putting GNU/Hurd first, but I'd like to keep the structure of listing the exceptions after a colon to match the other item. So, how about: On GNU/Hurd systems, the following additional directories are allowed in the root filesystem: file/hurd/file and file/servers/file. footnote These directories are used to store translators and as a set of standard names for mount points, respectively. /footnote All good reasons so let's go with that one then. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Water, taken in moderation cannot hurt anybody. -- Mark Twain signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Mon, 2010-08-30 at 12:05 -0400, CJ Fearnley wrote: On Fri, Aug 27, 2010 at 10:38:14AM -0700, Russ Allbery wrote: CJ Fearnley c...@cjfearnley.com writes: 2.2.1 The main archive area The main archive area comprises the Debian GNU/Linux distribution; only the packages in this area are considered part of the distribution. None of the packages in the main archive area require software outside of that area to function. OK, how about this suggestion for a conclusion to Russ' text on the main archive area: Everyone (from end users to redistributors to derivatives) can be confident that they can use, share, modify and redistribute the software in the Debian main archive area freelyfootnoteSee http://www.debian.org/intro/free for more about what we mean by free software./footnote. It sounds a little My little pony-ish to me, but it's harmless enough. I think including a definition of 'Everyone in brackets potentially reduces the meaning of the word rather than enhances it. In some future time will someone say I'm not an end user, redistributor or derivative (deriver?) of Debian: am I part of 'Everyone'?. I'd prefer even more succinct brevity, along the lines of: Anyone may use, share, modify and redistribute the packages in the 'main' archive area freelyfootnoteSee http://www.debian.org/intro/free for more about what we mean by free software./footnote. software - packages, since not everything in 'main' is software. main - 'main' to make it clearer that it is a proper noun as capitalising it would not work. Other minor wording changes because it felt better to me that way, but I'm not wedded to them. Cheers, Andrew. and then going on to the language already there, which already requires that all the packages comply with the DFSG. 2.2.2 The contrib archive area The contrib archive area contains supplemental packages intended to work with the Debian GNU/Linux distribution, but which require software outside of the distribution to either build or function. Apart from this requirement, all software in the contrib archive area complies with the DFSG and with the policy requirements in this manual. 2.2.3 The non-free archive area The non-free archive area contains supplemental packages intended to work with the Debian GNU/Linux distribution that do not comply with the DFSG or have other problems that make their distribution problematic. They may not comply with all of the policy requirements in this manual due to restrictions on modifications or other limitations. I don't think any of the above changes anything normative, so once we reach consensus on the wording I can go ahead and apply this. -- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller CJ Fearnley| Explorer in Universe c...@cjfearnley.com | Dare to be Naive -- Bucky Fuller http://www.CJFearnley.com | http://blog.remoteresponder.net/ -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Never be led astray onto the path of virtue. signature.asc Description: This is a digitally signed message part
Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
On Sun, 2010-08-29 at 04:17 -0700, PJ Weisberg wrote: On Sat, Aug 28, 2010 at 1:34 PM, Russ Allbery r...@debian.org wrote: Charles Plessy ple...@debian.org writes: Le Fri, Aug 27, 2010 at 10:24:57AM -0700, Russ Allbery a écrit : In fields where the value may not span multiple lines, the amount of whitespace in the field body is not significant. Any amount of whitespace is equivalent to a single space. Whitespace must not appear inside names (of packages, architectures, files, or anything else) or version numbers, or between the characters of multi-character version relationships. I still have difficulties to understand the meaning of this paragraph, and to what fields it applies. Is it just specifiying that the parser, in the case of fields that allow continuation lines, can be either instructed to replace all white spaces and newlines by single spaces, or to leave the value as it is, including the new lines? No, it's really trying to say that the amount of whitespace isn't significant. I'm not sure how else to explain it. That's one of those precise terms of art for which there isn't really an acceptable synonym, at least not that I can think of. Replacing all whitespace with a single space is one of the things that you can do *because* the amount of whitespace is not significant, but it's not an equivalent statement. It might be more *precise* to say that the field contains a series of whitespace-delimited tokens, but I don't know if that would be more *understandable*. Given the target audience (i.e. the ornery DD :-) it seems likely to me that they would then want to know if those tokens can be quoted strings. The above text seems to me to remove the possibility of that question :-) Sure it's maybe a little wordy, but it's explicit also,and not too unreadable. Cheers, Andrew. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Time to be aggressive. Go after a tattooed Virgo. signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Sat, 2010-08-28 at 07:35 -0400, CJ Fearnley wrote: I don't think CJ is advocating changing the DFSG, but rather is concerned that the way the DFSG is worded may not make it clear to people what the motivation is and what the implications are for users. In other words, a rephrasing or preamble, not any sort of normative modification, that says this means you can use the software for absolutely anything you want. I can see that point, although I'm not sure that it makes that much difference for Policy, since Policy is largely aimed at people who are reasonably familiar with Debian and are looking for technical guidance. I would tend to point people at http://www.debian.org/intro/free or some similar sort of place to explain the motivation and background for what Debian means by free. Russ' interpretation of my thinking is correct. I certainly don't want to change the DFSG. I'm thinking about a customer who is afraid of using Debian for some business purpose, for example. Their lawyers have spread fear and uncertainty: beware, the BSA[1] may come after you. They read the DFSG and they learn what we mean by freedom, but they still might not connect the dots to realize that Debian main is doing its best to effectively guarantee ... the four freedoms ... the best protection against BSA interference that a mere document can provide ... what we all know is our protected freedom. But I think we haven't said it directly enough. http://www.debian.org/intro/free is good for a footnote, but it also doesn't succinctly say that Debian main tries to ensure that it can be freely usable and redistributable (with the requisite freedom protections for your users too) by anyone for any purpose. Phew :-) I still think I side with Russ that Policy is for people who already understand this stuff, and we should have separate documents that provide the overview level. I also think that proper clarification on these points will ideally need a multi-lingual and multi-cultural dimension to capture the exact shades of meaning needed. Regards, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You've been leading a dog's life. Stay off the furniture. signature.asc Description: This is a digitally signed message part
Bug#594658: debian-policy: Add FHS exception for GNU/Hurd directories
On Sat, 2010-08-28 at 09:08 +0200, Guillem Jover wrote: Source: debian-policy Source-Version: 3.9.1.0 Severity: wishlist Tags: patch X-Debbugs-CC: debian-h...@lists.debian.org Hi! Here's a draft patch to add an FHS exception for the two top-level directories GNU/Hurd uses. Hi Guillem, I would change the text around a little to add that to the beginning of the paragraph, something like: On GNU/Hurd systems the file/hurd/file and file/servers/file directories are also allowed in the root filesystem. footnoteThese directories are used to store translators and as a set of standard names for mount points respectively./footnote Ordering the words in this way means the reader can decide it's applicability much faster. Perhaps splitting the footnote into two footnotes might help also: ... file/hurd/filefootnoteUsed to store translators./footnote and file/servers/filefootnoteUsed as a set of standard names for mount points./footnote ... It might make sense to merge with the /sys and /selinux paragraph, and the footnote might need to be clarified probably. It might, although I think starting the paragraph with On GNU/Hurd ... might make it clearer when it stands on it's own. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN The difference between a crazy person and an intelligent one is that the crazy one doesn't realize what makes sense in the world. -- Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#106073: recommend to install package documentation into /usr/share/doc/package/
On Fri, 2010-08-27 at 10:16 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: My personal preference would be to encourage -doc packages to install their files into /usr/share/doc/package/docs - including their internal administrivia. That would break Lintian, apt-listchanges, probably the DAK processing scripts, and anything else that looks at copyright and changelog in binary packages. I don't think it's worth it to make that change. While this is not current practice, I'm not convinced that current practice has evolved into what was suggested in 2003 either. Right now, I'm seeing a real mix of behavior, with some packages installing all the documentation into the -doc package's /usr/share/doc (probably in part because that's easier) and others installing it into the parent package, some with symlinks and some without. As a result, right now one cannot easily find the documentation in any standardized place. I also remember as a user hunting for these documents the first time or two when I had installed the -doc package and it slowly dawning on me that they weren't anywhere in /usr/share/doc/package, and I think that breaks the principal of least surprise, for everyone except long-time, hard-core Debianista. Yeah, that's what Ben's writeup would fix, and I agree that's worth fixing. Those points are justifications for both proposals, of course, and I guess that one reason for retaining the administrivia in /usr/share/doc/package-doc might be that there are tools that expect to find it there. Is that the case? Yup. I don't think I ever do more than refer to them by hand, and either proposed change can probably be codified in some small number of scripts. I don't think the change proposed here requires changing any scripts, although it will require changing a bunch of packages (and a change to debhelper to make it easier to install docs into the right place would be useful). In that case I support changing it the way Ben proposes. I can certainly see the value of standardising it, and doing it this way definitely improves the situation. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I'll burn my books. -- Christopher Marlowe signature.asc Description: This is a digitally signed message part
Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas
On Fri, 2010-08-27 at 18:06 -0400, CJ Fearnley wrote: On Fri, Aug 27, 2010 at 12:17:16PM -0700, Russ Allbery wrote: CJ Fearnley c...@cjfearnley.com writes: However, I do wish that we could figure out how to write a minefield-avoiding third sentence for your paragraph on the main archive area that definitively asserts (what I believe we all know to be true) that Debian main is more or less a guarantee that the software therein is freely usable (and distributable) in the broadest sense. That is, that Debian main is unreservedly usable for personal, non-profit, for-profit, or, in short, for any purpose. But I'm blanking on text that would work. Isn't that basically what the DFSG says, though? At least, that was the logic that I was using. The DFSG defines freedom in software licenses, but doesn't provide a statement of assurance to users. Maybe a statement that Debian main supports the Four Freedoms[1][2] would turn the prescriptive DFSG into a qualitative benefits statement. Hi, I think that you're treading on thin ground pushing for that. The DFSG is a defining document in Debian, so if you want to narrow or broaden that coverage you should be doing so by promoting changes to that document - not to policy. Personally I'm happy with the freedoms described by the DFSG as it stands at present, but if you believe it is flawed you should argue those flaws in the wider arena of Debian via a GR or such. The clarifications Russ suggested definitely do seem worth including, and I would say it is especially because they refer out to that defining document that gives them their strength in policy. If they were to place additional constraints on what software was acceptable in main it would make policy more confusing, not less, and would undermine the DFSG as a decision-making tool. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN A tall, dark stranger will have more fun than you. signature.asc Description: This is a digitally signed message part
Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.
On Thu, 2010-08-26 at 10:05 +0900, Charles Plessy wrote: Le Sun, Aug 22, 2010 at 03:23:26PM +0900, Charles Plessy a écrit : I have been reading §5.1 (Syntax of control files) many times recently, and would like propose clarifications about a couple of points. If consensus emerges, I will write a patch. Non-wrappable field values Ordering of the paragraphs Line escape and paragraph separators Hi again, to this list I would like to add comment lines. Currently they are described in §5.2 (5.2 Source package control files -- debian/control), as an additional syntax, which strongly suggests that they are allowed in this file only. Independantly of whether this is confirmed or not, this syntactic information would rather belong to §5.1, that defines the syntax of the control files, instead of §5.2, which like the next chapters §5.3–6 lists the fields allowed in the different Debian control files. I would therefore propose to have in §5.1: Lines starting with # without any preceding whitespace are ‘comments lines’ and are ignored, even in the middle of continuation lines for a multiline field. They do not end a multiline field. If comment lines are only allowed in source package control files, we could add: The use of such comments must be allowed on a per-file basis. And then in §5.2: Comment lines are allowed. The benefit of this is that it concentrates in §5.1 all the instructions to write a basic parser for Debian control files. This seems sensible, and I think all of the clarifications you plan are in the same light, and I would certainly support a patch expressing this all more clearly. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn signature.asc Description: This is a digitally signed message part
Bug#594274: debian-policy: Don't track generated README documents in VCS
On Wed, 2010-08-25 at 14:28 +1000, Ben Finney wrote: On 25-Aug-2010, Ben Finney wrote: However, the VCS repository also contains the rendered documents themselves. Those should not be tracked in VCS; instead, they should be generated from source as needed. I couldn't find a way to tell Git “these files are removed from the repository, propagate that fact to other repositories”. (Git doesn't seem to track file removal as such, making me wonder if it's even possible to do this in a robust way with Git.) So attached is a Bazaar diff output, that hopefully contains enough information for someone more knowledgeable about Git to do the right thing. git rm directory/file.name git commit Of course if you've already removed the files it is less obvious. :-) Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will be traveling and coming into a fortune. signature.asc Description: This is a digitally signed message part
Bug#106073: recommend to install package documentation into /usr/share/doc/package/
On Wed, 2010-08-25 at 14:55 +1000, Ben Finney wrote: On 27-Sep-2003, Josip Rodin wrote: Some proposed mandating that -doc package contents is placed into /usr/share/doc/package/, and that the administrivia such as copyright and changelog stays in /usr/share/doc/package-doc/. This sounds good to me because it has a sort of an internal logic, the -doc suffix only exists because of packaging, it's actually the docs for package. Plus, it's shorter, less to type. There seems to be consensus on doing this, so I've made a patch (attached to this message) which implements that recommendation. Hi Ben, Thanks for the patch, but since that was from 2003 I wonder if it deserves a little more discussion now, before we apply it. My personal preference would be to encourage -doc packages to install their files into /usr/share/doc/package/docs - including their internal administrivia. While this is not current practice, I'm not convinced that current practice has evolved into what was suggested in 2003 either. While both proposals would move the package-doc content to under /usr/share/doc/package, I would prefer to see a reduction in the number of directories under /usr/share/doc - admittedly on my own system this would only be around 1% reduction. I also remember as a user hunting for these documents the first time or two when I had installed the -doc package and it slowly dawning on me that they weren't anywhere in /usr/share/doc/package, and I think that breaks the principal of least surprise, for everyone except long-time, hard-core Debianista. I think it particularly confuses people when the -doc package first splits out of the original package, since the docs get moved away at that point. Those points are justifications for both proposals, of course, and I guess that one reason for retaining the administrivia in /usr/share/doc/package-doc might be that there are tools that expect to find it there. Is that the case? I don't think I ever do more than refer to them by hand, and either proposed change can probably be codified in some small number of scripts. Cheers, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Change your thoughts and you change your world. signature.asc Description: This is a digitally signed message part
Bug#593533: debian-policy: Proposal to stop requesting to list initial Debian maintainers in debian/copyright
On Wed, 2010-08-18 at 19:10 -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Information about the initial Debian maintainers partially overlaps the information in debian/changelog, and the copyright statements for the packaging work. Under normal circumstances, it always duplicates information in debian/changelog (there are some edge cases where it doesn't, but I think they're rare). diff --git a/policy.sgml b/policy.sgml index 9037de8..e924b5a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -9554,9 +9554,8 @@ END-INFO-DIR-ENTRY 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. + sources (if any) were obtained, and should name the original + authors. /p p Seconded. Seconded. While I understand Cate's point about recognition of Debian Developers, this is about removing the policy requirement that they be acknowledged in this way and leaving them the choice to be acknowledged. It seems to me that making the decision to be a decision of the maintainer is perfectly correct. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Let me put it this way: today is going to be a learning experience. signature.asc Description: This is a digitally signed message part
Bug#593611: Acknowledgement (debian-policy: Clarify whose signature should go in debian/changelog (4.4))
On Thu, 2010-08-19 at 12:31 -0400, Felipe Sateler wrote: Argh, I misused reportbug, apparently. Here is the actual report: Policy 4.4 currently says: The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. One person I'm sponsoring misread this and put my name in the changelog, since I'm the one actually doing the upload. I can't think of a better wording, though. Perhaps a footnote is enough? Hi Felipe, I would say that as the person sponsoring and signing the upload you are the person who is responsible for it, and the changelog should show your name. Perhaps the person who did the bulk of the work before you reviewed the package and uploaded it should put their name as a line in the changelog saying something like: * Packaging by Joe Cool j...@example.cool for sponsored upload. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN What I tell you three times is true. -- Lewis Carroll signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Mon, 2010-06-28 at 10:58 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote: Ok, I agree that it would a good idea to include GPL-1 in common-licenses because of the high number of packages still using it. I'm sorry, but I disagree, for the time being. I do not believe that large numbers of packages are deliberately using GPL v1, and I think that anyone who is needs to confirm that explicitly since (I hope) many of them have moved on to less broken licenses such as GPL3 or GPL2. Hi Andrew, Did the subsequent discussion resolve your concerns about including the GPL v1 in common-licenses? I do think there are a lot of packages that are explicitly distributed under GPL v1 or later due to the Perl licensing situation. I guess this is the status quo, so we should continue with it. The weight of opinion seems against me :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net signature.asc Description: This is a digitally signed message part
Bug#575639: Bug#567489: Clarify that Changed-By must have name and email address
On Sun, 2010-06-13 at 19:00 -0700, Russ Allbery wrote: Helps if I send this to the correct bug. Russ Allbery r...@debian.org writes: * maintainer-name-missing and uploader-name-missing are both automatic rejects in the ftp-master checks, which makes them automatically severity: serious in Lintian. That's not the specific one that you're asking about, but that's the rule that Changed-By references. * The Policy description for Changed-By says The name and email address of the person who changed the said package. That's not a should. That's a statement of what that field shall include, which means that if it doesn't have the name and e-mail address, it's a syntax error and therefore is a violation of an implicit must. I see where your reading is coming from, but suspect the best fix is to just change the Policy wording to make it clear that this is a must. There's really no reason to use a different format, and Debian elsewhere already requires names. Here's a proposed patch that cleans up the wording of Maintainer, Uploaders, and Changed-By to reflect current practice. There is another outstanding bug in this area to document further restrictions on Maintainer and Uploaders, but this is the easy part so I wanted to resolve this first. The following patch tightens the syntax of Maintainer to a must, tightens the use of comma as a separator in Uploaders to a must, permits people to use multi-line Uploaders fields (we were waiting for the lenny release), and is explicit that the syntax of Changed-By is the same as Maintainer and is a bit clearer about what goes into that field. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index df6ae89..5a76cf3 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2672,7 +2672,7 @@ Package: libc6 p The package maintainer's name and email address. The name - should come first, then the email address inside angle + must come first, then the email address inside angle brackets ttlt;gt/tt (in RFC822 format). Missing semicolon: brackets ttlt;gt;/tt (in RFC822 format). /p @@ -2690,17 +2690,16 @@ Package: libc6 sect1 id=f-Uploaders headingttUploaders/tt/heading - p -List of the names and email addresses of co-maintainers of -the package, if any. If the package has other maintainers -beside the one named in the -qref id=f-MaintainerMaintainer field/qref, their -names and email addresses should be listed here. The -format is the same as that of the Maintainer tag, and -multiple entries should be comma separated. Currently, -this field is restricted to a single line of data. This -is an optional field. - /p + p + List of the names and email addresses of co-maintainers of + the package, if any. If the package has other maintainers + beside the one named in the + qref id=f-MaintainerMaintainer field/qref, their names + and email addresses should be listed here. The format is the + same as that of the Maintainer tag, and multiple entries must + be comma separated. This is an optional field. + /p + p Any parser that interprets the Uploaders field in filedebian/control/file must permit it to span multiple @@ -2714,9 +2713,10 @@ Package: libc6 headingttChanged-By/tt/heading p - The name and email address of the person who changed the - said package. Usually the name of the maintainer. - All the rules for the Maintainer field apply here, too. + The name and email address of the person who prepared this + version of the package, usually a maintainer. The syntax is + the same as for the qref id=f-MaintainerMaintainer + field/qref. /p /sect1 Seconded. Presuming you've fixed the missing semicolon that Sean spotted :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You are taking yourself far too seriously. signature.asc Description: This is a digitally signed message part
Bug#104373: Subdirectory under /usr/lib/cgi-lib should be explicitly allowed
On Sat, 2010-06-12 at 12:35 -0700, Russ Allbery wrote: Rémi Perrot remi.per...@torrep.org writes: In section 12.5 of the policy it like that it is not possible to put cgi script in /usr/lib/cgi-lib/package-name/cgi-name If this is true, we will have more and more file name conflict, and these conflict are quite hard to resolve due to link change across the application. These already many package that violate this rules. If this is false, please can we have more explanation in the policy. Despite its age, this bug is rather straightforward and is something we really should have fixed years ago. The current wording around locations of CGI programs implies that subdirectories of /usr/lib/cgi-bin may not be used, but of course this is very widely used in packages already in the archive and works with a typical web server configuration. Here is a patch that explicitly allows this. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 720150d..7dd0785 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8184,11 +8184,13 @@ done example compact=compact /usr/lib/cgi-bin/varcgi-bin-name/var /example - and should be referred to as + or a subdirectory of that directory, and should be + referred to as example compact=compact http://localhost/cgi-bin/varcgi-bin-name/var /example - + (possibly with a subdirectory name + before varcgi-bin-name/var). /item item Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Wrinkles should merely indicate where smiles have been. -- Mark Twain signature.asc Description: This is a digitally signed message part
Bug#555978: debian-policy: Forbid duplicate fields in control files
On Sat, 2010-06-12 at 18:18 +0900, Charles Plessy wrote: Le Fri, Jun 11, 2010 at 09:58:28AM -0700, Russ Allbery a écrit : diff --git a/policy.sgml b/policy.sgml index 87b9795..99ab0ff 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2398,6 +2398,11 @@ Package: libc6 /p p + Each paragraph may contain at most one instance of a particular + field name. + /p + + p Many fields' values may span several lines; in this case each continuation line must start with a space or a tab. Any trailing spaces or tabs at the end of individual Hi Russ, as a non-native speaker, I have difficulties with the use of 'may' in your patch: if fields may be unique, they also may be not unique, so what is the message in this sentence? It does not give me the impression that the goal is to discourage the use of the same field name twice in the same paragraph. How about “A paragraph should not contain data fields having the same name.” Hi Charles, In this sense 'may' should be read as 'must', however I think that if it causes readability issues for non-native english speakers then the word 'must' should actually be used... Each paragraph must contain at most one instance of a particular field name. Is that clearer? Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Building more free and open source software for New Zealanders signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote: Ok, I agree that it would a good idea to include GPL-1 in common-licenses because of the high number of packages still using it. I'm sorry, but I disagree, for the time being. I do not believe that large numbers of packages are deliberately using GPL v1, and I think that anyone who is needs to confirm that explicitly since (I hope) many of them have moved on to less broken licenses such as GPL3 or GPL2. The blurb in debian/copyright has usually two parts. 'usually' is not sufficient. We need to explicitly know what the license is. Thus, I see no reason to use a versioned license when the license says version foo or later. Well, that's OK, perhaps, if you have confirmed that the software license of the upstream project has that text, except that *exactly* that text might be the *only* difference from the standard text. If we have a common license which is GPL-1-or-later in common licenses I would be OK with. I would not be ok with a common license of GPL-1 only, because (a) hopefully it is rare and (b) it is acknowledged to be old and broken, to some degree, and should be discouraged. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Try to value useful qualities in one who loves you. signature.asc Description: This is a digitally signed message part
Bug#436105: suggestion to add GPL-1 as a common licence
On Fri, 2010-06-11 at 14:14 +0200, Giacomo A. Catenazzi wrote: Yes for new code, but old code cannot be relicensed easily: all authors should agree, but GPLv1 is very old, in periods where contribution did not have an email and fix (live-long) email address was not common. It is: (a) old code (b) not a common license Regardless of whether it may once have been. BTW unilaterally moving version 1 and any later versio to version 2 [or 3] and later later is against the GPL. Nobody is suggesting that code licensed under v1 can be moved to v2 (or later) without the authority of the author(s). So I think that GPLv1 will remain important for the time being, and I would include it in common-license. I think the project should actively rate it as 'unimportant', at least partly in order to draw attention to the fact that it is using an obsolete license. If the code is v1-or-later then a trivial fork (by the original developer) is able to relicense it as v2-or-later or v3-or-later. If the original developer is unhappy with doing that, then they do have uncommon licensing desires. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't you feel more like you do now than you did when you came in? signature.asc Description: This is a digitally signed message part
Bug#224509: Don't require a TTY during maintainer script execution
On Thu, 2010-06-03 at 09:34 -0700, Russ Allbery wrote: The previous discussion on this bug didn't reach a final consensus on wording, but I still believe we have a consensus that this is the right general direction. Here's an updated patch that includes the permission suggested by Steve Langasek for maintainer scripts to abort for high-priority questions without a reasonable default, but with a caution against setting up that situation. I'm looking for seconds or further discussion if people don't believe that this is the right direction to go. diff --git a/policy.sgml b/policy.sgml index af00c0e..3f6b82d 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3557,15 +3557,26 @@ Files: headingControlling terminal for maintainer scripts/heading p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting tt$|=1/tt so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ref id=maintscriptprompt) may + assume that program will handle falling back to noninteractive + behavior. + /p + + p + For high-priority prompts without a reasonable default answer, + maintainer scripts may abort if there is no controlling + terminal. However, this situation should be avoided if at all + possible, since it prevents automated or unattended installs. + In most cases, users will consider this to be a bug in the + package. /p /sect + sect id=exitstatus headingExit status/heading @@ -9537,9 +9548,9 @@ END-INFO-DIR-ENTRY /p p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See ref id=controllingterminal. + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See ref id=controllingterminal. /p /item Seconded. This is definitely in the right direction and I think the wording has enough of an escape clause in it, but with just the right amount of deterrent. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Fine day for friends. So-so day for you. signature.asc Description: This is a digitally signed message part
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Thu, 2010-06-03 at 22:01 +0200, Guillem Jover wrote: Hi! On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote: Okay, here's another try at this patch that removes some extraneous information that it sounds like we shouldn't get into, from this message and your other message, and tries to simplify the wording to address the issue raised in the message whose URL is given above. Thanks! diff --git a/policy.sgml b/policy.sgml index af00c0e..36c7a1f 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2735,41 +2735,62 @@ Package: libc6 ttArchitecture/tt field can include the following sets of values: list - itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. - itemttall/tt, which indicates an - architecture-independent package. - itemttany/tt, which indicates a package available - for building on any architecture. - itemttsource/tt, which indicates a source package. + item + A unique single word identifying a Debian machine + 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. + ttany/tt matches all Debian machine architectures + and is the most frequently used. + /item + item + ttall/tt, which indicates an + architecture-independent package. + /item + item + ttsource/tt, which indicates a source package. + /item /list /p 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 the special value ttall/tt + or a list of specific and wildcard architectures separated by + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Most packages will use “any” must also only appear by itself (that got lost from the previous text). + either ttany/tt or ttall/tt. + /p + + p + Specifying a specific list of architectures indicates that the + source will build an architecture-dependent package only on + architectures included in the list. Specifying a list of + architecture wildcards indicates that the source will build an + architecture-dependent package on only those architectures + that match any of the specified architecture wildcards. + Specifying a list of architectures or architecture wildcards + other than ttany/tt is for the minority of cases where a + program is not portable or is not useful on some + architectures. Where possible, the program should be made + portable instead. /p p In the source package control file file.dsc/file, this - field may contain either the special value ttany/tt or a - list of architectures separated by spaces. If a list is given, - it may include (or consist solely of) the special value - ttall/tt. In other words, in file.dsc/file files - unlike the filedebian/control/file, ttall/tt may occur - in combination with specific architectures. The - ttArchitecture/tt field in the source package control file - file.dsc/file is generally constructed from the - ttArchitecture/tt fields in the - filedebian/control/file in the source package. + field may contain either the architecture + wildcard ttany/tt or a list of architectures and + architecture wildcards separated by spaces. If a list is + given, it may include (or consist solely of) the special + value ttall/tt. In other words, in file.dsc/file + files unlike the filedebian/control/file, ttall/tt may + occur in combination with specific architectures. + The ttArchitecture/tt field in the source package control + file file.dsc/file is generally constructed from + the ttArchitecture/tt fields in + the filedebian/control/file in the source package. /p p @@ -2789,23
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On Thu, 2010-06-03 at 18:31 -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: I also like the idea, so I prepared a patch (attached) Thank you! RFC 822 dates use only two digits for the years, but Debian changelogs described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch replaces the reference to the RFC 822 by a specification that is compatible with its successors, RFC 2822 and RFC 5322, but does not use their full range of options. --- policy.sgml | 26 ++ 1 files changed, 22 insertions(+), 4 deletions(-) diff --git a/policy.sgml b/policy.sgml index af00c0e..5ba1980 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1618,11 +1618,29 @@ /p p - The vardate/var must be in RFC822 formatfootnote + The vardate/var has the following formatfootnote This is generated by ttdate -R/tt. - /footnote; it must include the time zone specified - numerically, with the time zone name or abbreviation - optionally present as a comment in parentheses. + /footnote (compatible and with the same semantics of + RFC 2822 and RFC 5322): + exampleday-of-week, dd month hh:mm:ss +/example + where: + list compact=compact + itemday-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun/item + itemdd is a one- or two-digit day of the month (01-31)/item + itemmonth is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec/item + item is the four-digit year (e.g. 2010)/item + itemhh is the two-digit hour (00-23/item + itemmm is the two-digit minutes (00-59)/item + itemss is the two-digit seconds (00-60)/item + item + + or - is the the time zone offset from Coordinated Universal + Time (UTC). + indicates that the time is ahead of (i.e., east of) UTC + and - indicates that the time is behind (i.e., west of) UTC. The + first two digits indicate the hour difference from UTC and the last + two digits indicate the number of additional minutes difference from + UTC. The last two digits must be in the range 00-59. + /item + /list /p p Seconded. Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN You're being followed. Cut out the hanky-panky for a few days. signature.asc Description: This is a digitally signed message part
Bug#569174: [PATCH] Correction of RFC number for date format -- bug #569174.
On Wed, 2010-06-02 at 14:59 +0200, Bill Allombert wrote: On Tue, Jun 01, 2010 at 10:47:18AM +0900, Charles Plessy wrote: RFC 822 dates use only two digits for the years, but Debian changelogs described by this paragraph (§4.4 in Policy 3.8.4) use four digits. This patch replaces the RFC 822 by its latest evolution, RFC 5322, that specifies a date format suitable for Debian changelogs. --- policy.sgml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/policy.sgml b/policy.sgml index d16df70..7e2365e 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1610,7 +1610,7 @@ /p p - The vardate/var must be in RFC822 formatfootnote + The vardate/var must be in RFC5322 formatfootnote This is generated by ttdate -R/tt. /footnote; it must include the time zone specified numerically, with the time zone name or abbreviation -- 1.6.5.7 What is the diffrence between RFC5322 and RFC2822 time format ? RFC 5322 was only released in 2008, so the standard that packages actually follow is clearly RFC2822. I would prefer if we keep a reference to RFC2822 because is is more well known than RFC5322 The 'date' utility denotes this format under 'RFC 2822': The option is named --rfc-2822 and the documentation list RFC 2822. I disagree: We should migrate our documentation to use the newest version of such standards when the standards body concerned updates them. In this case RFC2822 is superseded by RFC5322, and so we should reference the newer version. The new standard has been out for two years, and we haven't done it already!? This makes it a bug for things to be incompatible with the newer standard, which overall makes the adoption of the newer standard easier. I'd be surprised if it actually has an effect on Debian in this case, which is even more of a reason to use the newer standard. Moving everyone to the new standard is often difficult (how many times do we still hear of RFC822 being referred to?) and we should help grease the wheels as much as possible. Filing a bug against coreutils for the date option naming is probably a good idea too - it is hopefully trivial for them to allow the option to also be referenced as --rfc-5322. They appear to have made this change in the past, because the --rfc-822 option also works, though it is undocumented. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Be cautious in your daily affairs. signature.asc Description: This is a digitally signed message part
Re: Bug#552690: mknod-in-maintainer-script postinst:39
Seconded. On Thu, 2009-11-12 at 13:29 -0800, 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 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ andrew (AT) morphoss (DOT) com+64(272)DEBIAN Flexibility is overrated. Constraints are liberating. signature.asc Description: This is a digitally signed message part
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Tue, 2009-09-29 at 13:39 -0500, Manoj Srivastava wrote: Hi, Given that there have been no objections or wording change suggestions, I would like to ask for seconds on this. + like in: + example + gnu-linux-i386 == gnu-linux-any + gnu-kfreebsd-amd64 == any-any-amd64 + /example A possibly confusing use of '==' there - would it be better to say 'is matched by'? Other than that quibble, I'm happy to second this. Regards, Andrew McMillan. http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust signature.asc Description: This is a digitally signed message part
Bug#543417: README.source patch system documentation requirements considered harmful
On Mon, 2009-08-24 at 15:46 -0700, Russ Allbery wrote: Chris Lamb la...@debian.org writes: If the motivation behind README.source is to highlight non-trivial packaging, then many packages can be presented that are trivial dispite using a patch system. My own conclusion is that the adoption of dpatch or quilt is so common that the skills for it may be assumed. To get things rolling, I propose that we temper: | This explanation should include specific commands and mention any | additional required Debian packages. It should not assume familiarity | with any specific Debian packaging system or patch management tools. .. with something subjective like any non-standard Debian packaging system. This would still ask maintainers to document the parts of their packages that would be unfamiliar to most developers, whilst avoiding maintainers including essays on how to invoke pbuilder and other nonsense. Whilst using a subjective like this isn't desirable, it does avoid having to enumerate specific programs that are exempt from explanation, which doesn't really smell right for the Policy. I'm increasingly inclined to agree with this, but I'd like to specifically spell out what the exceptions are. I think the important exception would be that packages that use quilt or dpatch in the default mode, applying all patches in debian/patches/series debian/patches/00list before the build and removing them on clean, aren't required to have a README.source. That should get most of the cases where this is simple boilerplate, while still preserving the requirement for uses of quilt or dpatch in a non-standard way. The implication is that people will have to know how quilt and dpatch work, but anything else has to be explained. I think anyone doing substantial Debian work has probably encountered quilt and dpatch at some point anyway and is at least vaguely familiar, so I think that preserves the original goal. I don't know if we should include CDBS's basic patch system as well. I'm inclined to agree with Lamby also. Although specifying a worthwhile list of exceptions does seem likely to become a slippery slope. Should we also be excluding packaging done through VCS branches from this requirement, for example? Regards, Andrew. http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN You have an ability to sense and know higher truth. signature.asc Description: This is a digitally signed message part
Bug#224509: Don't require a TTY during maintainer script execution
On Fri, 2009-08-07 at 19:43 -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Seconded. Cheers, Andrew. diff --git a/policy.sgml b/policy.sgml index 27deaa7..bf99884 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3529,15 +3529,17 @@ Package: libc6 headingControlling terminal for maintainer scripts/heading p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting tt$|=1/tt so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ref id=maintscriptprompt) may + assume that program will handle falling back to noninteractive + behavior. /p /sect + sect id=exitstatus headingExit status/heading @@ -9397,9 +9399,9 @@ END-INFO-DIR-ENTRY /p p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See ref id=controllingterminal. + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See ref id=controllingterminal. /p /item -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your nature demands love and your happiness depends on it. signature.asc Description: This is a digitally signed message part
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Mon, 2009-07-13 at 17:20 +0100, Julien Cristau wrote: On Mon, Jun 29, 2009 at 13:29:48 +0200, Bill Allombert wrote: I formally object to the part '(in other words, the size in kibibytes)'. (I believe this change is not informative and only serve the purpose of endorsing a standard which does not meet consensus in Debian.) It seems a sufficient quantity of people object to even the merest mention of 'kibibytes' as shorthand for 'bytes divided by 1024 and rounded' that only the fully expanded wording will be acceptable. The wording without it is unambiguous: The disk space is given as the integer value of the installed size in bytes divided by 1024 and rounded. I guess that perhaps the '-ibibytes' standard will eventually die, and everything will just become multiples of 1000, as it should be. In the meantime, regardless of the success of failure of the standard, this wording is at least correct for the current behaviour. My preferred wording would be to define it in terms of kibibytes, but include the explanation, since it seems it is an unfamiliar standard, as follows: The disk space is given as the integer value of the installed size in kibibytes (i.e. bytes divided by 1024). Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will never know hunger. signature.asc Description: This is a digitally signed message part
Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Mon, 2009-06-29 at 09:42 -0700, Russ Allbery wrote: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: On Tue, Jun 23, 2009 at 07:49:40PM -0700, Russ Allbery wrote: Agreed. At the time Policy was originally written, kilobyte nearly universally meant kibibyte in the industry. I'll change this to: The disk space is given as the integer value of the installed size in bytes divided by 1024 and rounded (in other words, the size in kibibytes). for the next release. (I believe this is an informative change that doesn't require seconds.) I formally object to the part '(in other words, the size in kibibytes)'. (I believe this change is not informative and only serve the purpose of endorsing a standard which does not meet consensus in Debian.) Okay. As previously mentioned, I disagree and would prefer to retain it, so I think at this point we need to hear more opinions to see how widespread the disagreement is. I'm happy with kibibytes, but on the other hand I'm also happy with kilobytes if the code is changed to actually report 1,000's of bytes. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Questionable day. Ask somebody something. signature.asc Description: This is a digitally signed message part
Re: Bug#534408: debian-policy: Installed-Size is defined as kilobytes but dpkg-gencontrol fills it in with kibibytes
On Thu, 2009-06-25 at 12:22 +1000, Ben Finney wrote: Russ Allbery r...@debian.org writes: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: I would prefer if the word kibibyte was not used in policy, so I would strike '(in other words, the size in kibibytes)'. I don't much like the word either, but at this point it's an IEEE and ISO standard (IEEE 1541-2002). My feeling is that standards are more important than aesthetics and we should generally follow established standards in areas like this unless there's some compelling reason not to. +1. The unit being discussed (number of bytes divided by 1024) has an internationally-accepted standard term, and even if we find the term ugly we should acknowledge that term in our use of that unit to clarify the intent. /AOL While a 'kilobyte' was a close enough approximation of a 'kibibyte', the percentage difference gets much more significant as we increase disk size. 1000 1024 102.40% 100 1048576 104.86% 10 1073741824 107.37% 1 1099511627776 109.95% 1000 1125899906842620 112.59% We should just use the right term, and we should collectively get over any dislike of it. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Let us not seek to satisfy our thirst for freedom by drinking from the cup of bitterness and hatred. -- Martin luther King Jr. signature.asc Description: This is a digitally signed message part
Re: Vcs-* and Other Fields
On Wed, 2009-06-24 at 00:17 -0400, Jonathan Yu wrote: Should this be something in the policy itself? I think so. But in general Policy doesn't document every possible field, only the ones with Policy significance. dpkg from time to time adds additional informational fields without needing a Policy section first. However, I think that ones that become established should gain Policy documentation so that we can be sure of interoperability, like we did with Homepage. For me it just seems odd to add fields to d/control that aren't in policy, though your explanation makes sense to me. Not at all. There is experimentation in advance of acceptance in this case, and I really don't believe that the overhead of sending every wacky proposal through policy before allowing it to be in the control file would not help the development of new features. proposed specification. For Lintian, we had trouble finding documentation for what the contents should be for some cases, particularly Vcs-Mtn. From the Developer's Reference, Vcs-Mtn refers to the mtn (Monotone) version control system. I don't really think that each version control system should have its own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not very future proof in my opinion. On the other hand we've got situations where there are lots of Version Control systems that use HTTP and WebDAV (like SVN via http://) so it's hard to detect what type of repository something is simply given the URL. I tend to agree, though in reality we essentially do have a two-part identifier, and if we define it as such there is no reason why we can't say that the field is 'Vcs-' + vcs-type + ':' + vcs-url, and future proof it by allowing the list of vcs-types to be defined outside of policy. It looks like the intent of having several fields for different Vcs mechanisms is that you can put several systems per package. So if you maintain your package in Svn and Git, you could have Vcs-Svn and Vcs-Git repositories for that. Indeed. And it might be possible to have mirrors defined, too, where the type is the same. It seems like it's reached the point where it's an ad-hoc standard and I think that makes it a reasonable candidate for inclusion into Debian Policy, though this might mean hammering out a clearer standard. Yes, I agree, it seems to be fairly actively used, and is probably time to review the current design and put something into policy. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Fine day to work off excess energy. Steal something heavy. signature.asc Description: This is a digitally signed message part
Bug#530687: debian-policy: Please provide policy for architecture wildcards
On Wed, 2009-05-27 at 14:33 -0400, Andres Mejia wrote: Current policy has this wording and I didn't want to change that, so yes, it's on purpose. Not quite. Current policy says arch list or 'any' or 'all' and that's fine (at least for debian/control), because it wouldn't make sense for a binary package's Architecture field to be 'any' or 'all' *plus* an explicit list of architectures. (yes, .dsc might need different rules, but.) Ok, here's the wording current policy. one may specify a list of architectures separated by spaces, or the special values any or all. Here's part of my proposal. one may specify a list of architectures separated by spaces, a list of architecture wildcards separated by spaces, or the special values any or all. As a native english speaker that wording seems to me to imply (list of specific and/or wildcard architectures) or (any) or (all), which seems to be what you intend, but I guess it is open to possible misinterpretation in the manner Julien suggests. How about: ... a list of specific and wildcard architectures separated by spaces, or the special values 'any' or 'all'. Cheers, Andrew. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530687: debian-policy: Please provide policy for architecture wildcards
://lists.debian.org/debian-devel/2009/02/msg00290.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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.9.2 utilities to manage online documen -- no debconf information Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Q: What lies on the bottom of the ocean and twitches? A: A nervous wreck. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530378: debian-policy: allow /usr/share/doc/package to point to another indirectly-depended-upon package's dir
On Sun, 2009-05-24 at 16:07 +0200, Serafeim Zanikolas wrote: Policy allows a package's doc directory to be a symlink to another package's doc directory, as long as they are: - from the same source package and - the first package directly depends upon the second I propose that that the second requirement is relaxed to allow for an indirect dependency of the first package to the second (as long as all packages involved have the same source). Hi, I don't like the idea of muddying policy with this sort of convoluted exception, and I can't see the value of it from a technical perspective. Regards, Andrew McMillan. Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Necessity is the mother of documentation -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines
On Sat, 2009-05-16 at 02:10 -0500, Manoj Srivastava wrote: It is my recollection that each field in the control file (and perhaps others) was supposed to follow rfc822 (now rfc5322), and that says: , |Each header field is logically a single line of characters comprising |the field name, the colon, and the field body. For convenience |however, and to deal with the 998/78 character limitations per line, |the field body portion of a header field can be split into a |multiple-line representation; this is called folding. The general |rule is that wherever this specification allows for folding white |space (not simply WSP characters), a CRLF may be inserted before any |WSP. | | The process of moving from this folded multiple-line representation | of a header field to its single line representation is called | unfolding. Unfolding is accomplished by simply removing any CRLF | that is immediately followed by WSP. Each header field should be | treated in its unfolded form for further syntactic and semantic | evaluation. An unfolded header field has no length restriction and | therefore may be indeterminately long. ` So, each field is always one logical line, but may consist of multiple physical lines. I suggest we add explanation like this to the policy document. It seems reasonable that we should follow this manner of specification, but will this introduce any issues for fields which are currently defined as multiple lines? If we applied this unfolding to the description, for example, we would lose the line break information, so I suspect we can't just pile straightforwardly onto this bandwagon, but would need to make it explicit that some fields cannot be unfolded in this manner. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Be careful! Is it classified? -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527871: Update information about DEB_*_ARCH variables
On Sat, 2009-05-09 at 06:45 +0200, Guillem Jover wrote: Package: debian-policy Version: 3.8.1.0 Severity: wishlist Tags: patch Hi! Recommend using the DEB_*_ARCH_CPU and DEB_*_ARCH_OS variables instead of the GNU style ones. And mention that the latter are mostly intended for use with upstream build systems, and not Debian packaging. Seconded. Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your step will soil many countries. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Mon, 2009-05-04 at 07:35 +0200, Guillem Jover wrote: On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote: we have an unfortunate situation where the practice in dpkg-buildpackage and the policy do not match fully. ... So I think for next dpkg upload we should make dpkg-buildpackage stop setting any flags by default, and switch the setting to go through the command line arguments to override the package options instead of the environment, so this would become the user override part. The DEB_VENDOR env var should not be set either, and we should work on getting a dpkg-vendor instead, before people try to start using the variable. Then if we get consensus that this is the righ path, agree on the makefile names (as once decided it will be a pain to change later on in all packages), we'll need to ship the distro defaults file somewhere and start fixing packages to include that makefile. The files could look something like: ,-- /usr/share/dpkg/build-options.mk # distro defaults FOO := distro -include /etc/dpkg/build-options.mk `-- ,-- /etc/dpkg/build-options.mk # site overrides #FOO := site `-- ,-- debian/rules -include /usr/share/dpkg/build-options.mk # package overrides FOO := pkg `-- ,-- command line # user overrides $ make -f debian/rules FOO=cmd That was really a very well-spent two months! +1 from me :-) Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will be advanced socially, without any special effort on your part. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
locale. No? so what it misses? - other alphabetic, numeric, currency, whitespace characters? But not UTF-8 local provides all characters: they define only the needed range for the language [see wikipedia, which should code UTF-8 as binary for this reason]. The C spoken language require only ASCII-7 (or maybe only a subrange of it). So why we need further characters? Note: whitespace are restricted in C locale by POSIX, in only two values We could use charset UTF-8 for C locale, declaring unused/illegal all c 127. Whould this solve the problems with mksh? I don't think so, so what you need in this C.UTF-8? I still think that en_US.UTF-8 is the right default (note: I'm not a US citizen, nor I speak English). Note that this proposal is not that we change the default sort ordering or character typing, which en_US *would* do (vs C). This proposal (if it were that strong) would be pushing for adoption of UTF-8 encoding as the default encoding. It isn't as strong as that, though. It is merely pushing for the *availability* of a UTF-8 locale on a default install. The installation will install the correct locale, so the en_US period is very short (we'll dominate them ;-) ). On debootstrap/pbuild/... things are different. But if it this the problem, let check a solution for building environment (and I still think that in this env en_US.UTF-8 could be nice. But I'll prefer a simple basic ASCII-7 C for basic/plain build, and only after packager thinks if it is a bug or a feature to have a specific build with UTF-8, it should manually set it. Why build need to depend to a locale? UNIX way is to allow to compile things for remote (maybe other OS, other arch) system. For testing? So why not test various locales (UTF-8, but also other non ascii based encodings) What environments people build or test in is a separate issue to what environments are available to them to build or test in, and indeed Steve Langasek has already suggested a seemingly reasonable workaround for the immediate problem which was, funnily enough, that mksh wants to have a UTF-8 locale *available* in order for it to *test the build*... So we could close this bug as 'why bother', really, but the discussion is much more important than that. Regards, Andrew McMillan. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
On Wed, 2009-04-08 at 14:17 +0200, Holger Levsen wrote: Hi, On Mittwoch, 8. April 2009, Paul Wise wrote: How about this: Game a gets installed and ships /var/games Game b gets installed and ships /var/games Game a gets purged and removes /var/games User starts game b and gets a high score Game b tries to save the high score but fails because /var/games doesn't exist Uhm, I thought it was obvious that /var/games may only be deleted if it's empty... But Paul is describing a situation where it is empty (Game b installed it, but has not yet written a high score into it), but the simple rmdir logic will delete it. == very bad. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You have no real enemies. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
On Wed, 2009-04-08 at 14:04 +0200, Adeodato Simó wrote: + Russ Allbery (Mon, 06 Apr 2009 11:33:41 -0700): I don't see much real benefit in going out of our way to remove /var/games and it looks like it would be a bit annoying (at the least, require adding purge code to all games that put files in /var/games that would usually never be triggered). My inclination would be to say that this behavior is fine and perhaps we should officially bless it somewhere. I agree with this. We’re trying to move away (eg. with triggers) from stuff that has to be propagated to every maintainer scripts, and I really don’t see how removing an empty /var/games is such a big benefit that would make it worth our time to enforce rmdir’s everywhere. /me too, for what it's worth. Additionally, what happens if package A and B both ship an empty /var/games (they both write their score files directly there, rather than a subdirectory), get both installed, then B gets purged and its postinst removes /var/games, and then A runs and tries to write to /var/games a score file, but the directory does no longer exist nor has the game write permission to create it. Is there or is there going to be a policy mandating that packages should not ship /var/games without shipping /var/games/name? I think the suggestion was shorthand for purge behaviour something along the lines of: rm /var/games/myscorefiles.* rmdir --ignore-fail-on-non-empty /var/games So that if the rmdir failed it was just kind of 'well, we tried' behaviour. Really, though, I don't think that sort of attitude is what we should ideally be enshrining in policy and I would rather bless the existence of /var/games than impose a more rigorous procedure for deleting it in a tasteful and elegant way. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Time to be aggressive. Go after a tattooed Virgo. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Wed, 2009-04-08 at 15:31 +0200, Giacomo A. Catenazzi wrote: We have the same objective, but two different ways. Indeed, but it seems to me that you are pushing for a much bigger change than I am. So the smallest step which is in the same direction both of us want to go, is for *a* UTF-8 locale to be *available* on all Debian systems, which is what is being proposed by this bug. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Just to have it is enough. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
On Tue, 2009-04-07 at 22:32 +0200, Adeodato Simó wrote: It is my impression that more packages than mksh could use an UTF-8 locale at build time (I’m afraid I don’t have pointers, but I’m sure I’ve come across at least a couple). Wouldn’t it be just better to change Debian’s default to make an UTF-8 locale available by default, rather than to force all those packages to play tricks with LOCPATH? I too would really like to see a UTF-8 locale available by default, and would prefer to see this be the C.UTF-8 locale, which doesn't screw with the collation / character type settings like any other UTF-8 locale would. It seems to me that the consensus here is that having a UTF-8 locale available is a good idea and I don't hear any very strong argument against such a change. Consequently I think we should move on from the discussion and start working out a patch to resolve this in policy. Regards, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Time to be aggressive. Go after a tattooed Virgo. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522364: debian-policy: Remove obsolete /var/mail transition requirement
On Thu, 2009-04-02 at 21:57 -0700, Russ Allbery wrote: Package: debian-policy Version: 3.8.1.0 Severity: minor This looks extremely obsolete. I think it can just be removed. Seconds? Seconded. Regards, Andrew. diff --git a/policy.sgml b/policy.sgml index 975df94..a5c9d13 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5697,12 +5697,6 @@ rmdir /usr/local/share/emacs 2/dev/null || true by any particular mail agents. The use of the old location file/var/spool/mail/file is deprecated, even though the spool may still be physically located there. - To maintain partial upgrade compatibility for systems - which have file/var/spool/mail/file as their physical mail - spool, packages using file/var/mail/file must depend on - either packagelibc6/package (gt;= 2.1.3-13), or on - packagebase-files/package (gt;= 2.2.0), or on later - versions of either one of these packages. /p /sect1 /sect -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=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.1 utilities to manage online documen -- no debconf information andrew (AT) morphoss (DOT) com+64(272)DEBIAN The goal of good engineering is not to ask what if?, but to ask how do I make this work as well as possible. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 2009-03-22 at 03:34 +, Noah Slater wrote: On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote: NEW rejections are even stronger than an RC bug. Apart from questions of whether that's useful documentation for users, I have a hard time seeing either of your reasons stated above as being RC-level bugs. You don't think that possible DFSG problems are RC bugs? :/ Do you mean as in guilty until proven innocent? Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You are fairminded, just and loving. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 16:44 -0700, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: Here's an updated patch to apply the following wording: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed. Seconded. That seems to be accepted by everyone, so I've pushed it to policy now. I hope that's the right thing... Please tell me if I've done something the wrong way, or whatever. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Courage is your greatest present need. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Fri, 2009-03-20 at 23:43 +0100, Julien Cristau wrote: On Sat, 2009-03-21 at 10:27 +1300, Andrew McMillan wrote: That seems to be accepted by everyone, so I've pushed it to policy now. I hope that's the right thing... Please tell me if I've done something the wrong way, or whatever. It looks like you've modified the 3.8.1.0 changelog entry instead of 3.8.2 :) Gah! Sorry - fixed now. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Open Source: the difference between trust and antitrust -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Wed, 2009-03-18 at 20:26 -0700, Russ Allbery wrote: Management Specification, version 2 or higher, unless no such interface is available when they are executed. Should we require that non-essential packages depend on debconf if they're going to do prompting? That wording implies to me that any package could check whether it was already installed (without a dependency) and fall back on non-debconf prompting, but I think that should only be permissible for essential packages. It seems to me that to mandate it that tightly is unnecessary. Surely it will be simpler for a maintainer who has added support for Debconf to just depend on it. Even if the maintainer does provide a workaround for an inessential package I can't see that it will matter to me: the important element is that they support the debconf interface, not to restrict what they might do in addition to that. The only other thing that I'm not sure about is what to do about preinst scripts. Are we requiring debconf for preinst prompting (and hence requiring a Pre-Depends) for non-essential packages? If a developer wants to prompt in their preinst (extremely rare, I believe, and explicitly recommended against in policy) then they certainly should either (a) pre-depend on debconf, or (b) provide a work-around solution for the case where debconf is not installed on the target system. The decision to pre-depend on debconf would seem like a no-brainer to the maintainer, I suspect. Since almost all packages *will* have situations where they are called when debconf is available they will (according to the wording above) all be required to use debconf. The fallback would only be chosen at execution time. Effectively I'm proposing that all packages needing user input must support debconf (or equivalent) - but also to recognise that some of them might be required to (install|configure|remove|...) with user input in it's absence and not to restrict them from Doing The Right Thing in that circumstance. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You will gain money by a fattening action. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 10:55 -0700, Russ Allbery wrote: Packages that are essential or that are dependencies of essential packages may fall back on another prompting method if no such interface is available when they are executed. Since we're essentially saying that all packages must support debconf, why bother restricting the set of packages which are allowed to provide a fallback? From a maintainer's POV surely they will only be working to provide a fallback if they desire their package to be installable when debconf is not available. I don't think we should second-guess their reasons for doing so. Our motivation here should be simply to ensure that all packages support debconf (or a future replacement), not to over-control what they can do in addition to that. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your true value depends entirely on what you are compared with. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Thu, 2009-03-19 at 13:59 -0700, Steve Langasek wrote: On Fri, Mar 20, 2009 at 09:13:19AM +1300, Andrew McMillan wrote: On Thu, 2009-03-19 at 10:55 -0700, Russ Allbery wrote: Packages that are essential or that are dependencies of essential packages may fall back on another prompting method if no such interface is available when they are executed. Since we're essentially saying that all packages must support debconf, why bother restricting the set of packages which are allowed to provide a fallback? Because the fallback is a worst case scenario, because testing for files on the filesystem is a poor proxy for determining whether the interface is in a usable state, and because adding the fallback code means duplicating logic in your maintainer script and making it way more complex than it needs to be. The fallback should only be permitted in Essential packages where it has to be there in order to avoid unbreakable loops; in all other cases, maintainers should properly declare their need for debconf and avoid making their maintainer scripts more clever and less robust. This also ensures that (assuming the maintainer is following policy) uses of debconf in preinsts are publically vetted by debian-devel before hitting the archive. OK, those are excellent reasons. Here's an updated patch to apply the following wording: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Flexibility is overrated. Constraints are liberating. diff --git a/policy.sgml b/policy.sgml index df586d1..8f02c12 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1218,17 +1218,16 @@ headingPrompting in maintainer scripts/heading p Package maintainer scripts may prompt the user if - necessary. Prompting should be done by communicating + necessary. Prompting must be done by communicating through a program, such as prgndebconf/prgn, which conforms to the Debian Configuration Management - Specification, version 2 or higher. Prompting the user by - other means, such as by handfootnote -From the Jargon file: by hand 2. By extension, -writing code which does something in an explicit or -low-level way for which a presupplied library -(emdebconf, in this instance/em) routine ought -to have been available. -/footnote, is now deprecated. + Specification, version 2 or higher. + /p + + p + Packages which are essential, or which are dependencies of + essential packages, may fall back on another prompting method + if no such interface is available when they are executed. /p p
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Wed, 2009-03-18 at 14:42 -0700, Russ Allbery wrote: I'm not sure how many of these were false positives, but I'm fairly sure that at least some of them are real: http://lintian.debian.org/tags/read-in-maintainer-script.html Not all that many, and some will be false positives. I think we should go for it... Yes. I think there was some sort of essential package exception discussed earlier in the bug (although even essential packages should try debconf first and fall back if it's not available, I think). I'd be very happy to see a policy change for this, so long as it allowed that packages may fall back if debconf (or other alternative) is not available. The current relevant text is: Package maintainer scripts may prompt the user if necessary. Prompting should be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher. Prompting the user by other means, such as by hand[9], is now deprecated. I think we should change that fairly simply to something like: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as debconf, which conforms to the Debian Configuration Management Specification, version 2 or higher, unless no such interface is available when they are executed. This: (a) changes the 'should' to a 'must'; (b) gives an out for those situations where debconf is not installed; (c) narrowly focuses that 'out' only to apply during execution (d) seems to me to be a simpler and more elegant approach than other wording proposals against this bug. I've attached a patch to that effect. Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't go surfing in South Dakota for a while. diff --git a/policy.sgml b/policy.sgml index df586d1..342b6c4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1218,17 +1218,11 @@ headingPrompting in maintainer scripts/heading p Package maintainer scripts may prompt the user if - necessary. Prompting should be done by communicating + necessary. Prompting must be done by communicating through a program, such as prgndebconf/prgn, which conforms to the Debian Configuration Management - Specification, version 2 or higher. Prompting the user by - other means, such as by handfootnote -From the Jargon file: by hand 2. By extension, -writing code which does something in an explicit or -low-level way for which a presupplied library -(emdebconf, in this instance/em) routine ought -to have been available. -/footnote, is now deprecated. + Specification, version 2 or higher, unless no such + interface is available when they are executed. /p p
Bug#509732: marked as done (Debian Policy doesn't include directive for filing RC bugs against the Policy)
reopen 509732 thanks It is truly classic irony that we see this one getting closed by spammers :-) andrew (AT) morphoss (DOT) com+64(272)DEBIAN Executive ability is prominent in your make-up. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470994: mail_spool default mode is 0660
On Sun, 2009-01-25 at 15:42 -0800, Russ Allbery wrote: This is a ping for this proposed change for additional seconds or objections. It would relax the requirement in Policy that mail spool files be mode 0660 and permit them to be mode 0600 if the MDA system used does deliveries as the user. --- a/policy.sgml +++ b/policy.sgml @@ -8062,12 +8062,27 @@ http://localhost/doc/varpackage/var/varfilename/var /p p - Mailboxes are generally mode 660 - ttvaruser/var:mail/tt unless the system - administrator has chosen otherwise. A MUA may remove a - mailbox (unless it has nonstandard permissions) in which - case the MTA or another MUA must recreate it if needed. - Mailboxes must be writable by group mail. + Mailboxes are generally either mode 600 and owned by + varuser/var or mode 660 and owned by + ttvaruser/var:mail/ttfootnote + There are two traditional permission schemes for mail spools: + mode 600 with all mail delivery done by processes running as + the destination user, or mode 660 and owned by group mail with + mail delivery done by a process running as a system user in + group mail. Historically, Debian required mode 660 mail + spools to enable the latter model, but that model has become + increasingly uncommon and the principle of least privilege + indicates that mail systems that use the first model should + use permissions of 600. If delivery to programs is permitted, + it's easier to keep the mail system secure if the delivery + agent runs as the destination user. Debian Policy therefore + permits either scheme. + /footnote. The local system administrator may choose a + different permission scheme; packages should not make + assumptions about the permission and ownership of mailboxes + unless required (such as when creating a new mailbox). A MUA + may remove a mailbox (unless it has nonstandard permissions) in + which case the MTA or another MUA must recreate it if needed. /p p I've read through the report in full and I'm happy to second this also. Regards, Andrew McMillan. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Software Licenced Under a Specific Version of GPL
Santiago Vila wrote: [ In reply to last Manoj's message ] Ok, let's suppose that we do things gradually, as you suggest. [ I'm trying to delegate the decision to the policy group, if possible ] Let's consider the following proposal: The GPL file in base-files should better be renamed to GPL-2 and GPL should be a symlink pointing to it. [ The proposal is independent of whatever step may come afterwards if/once it is implemented ]. I will gladly implement it if it gets the approval of the policy group, which, for this particular proposal, I understand it as three seconders (since I'm not proposing it myself) and no objections. If Ari will propose this (it is his problem, after all) I am happy to be one of the seconders. Regards, Andrew McMillan. -- _ Andrew McMillan, e-mail: Andrew @ catalyst . net . nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64(21)635-694, Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709
Re: Software Licenced Under a Specific Version of GPL
Ari Makela wrote: I asked because *I* didn't want to screw up my package. I've thought for years that Debian is in many ways the nicest OS for i386 (and of course for some other platforms) and when I've made packages I've tried to keep up the quality that Debian has. That's why I ask when I feel unsure what to do. I got some good advice and I'm going to follow it. I'm going to write a new file which says that /usr/share/common-licenses/GPL should have GPL version 2 and if it doesn't doesn't the user can get it from foo. If someone thinks this is a bad idea I'm open to other ideas. What you want to do seems perfectly reasonable to me, i.e. wishing to refer to a particular version of the GPL. I can see from various public forums that this way of using the GPL is likely to happen more often too. My belief is that the best approach would be to have /usr/share/common-licenses/GPL symbolically linked in a manner similar to library versions. This will mean that someone wishing to specify a particular version of the GPL can do so by a further symlink to the correct version. I can't see that this either (a) makes things worse, (b) is hard, or (c) is unreasonable. To make it happen you should file a wishlist bug against the package which provides the GPL, asking it to provide it as a versioned file and symlink /usr/share/common-licenses/GPL to the most recent version. Regards, Andrew. -- _ Andrew McMillan, e-mail: Andrew @ catalyst . net . nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64(21)635-694, Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709
Re: cleaning up our task packages
Joey Hess wrote: I suspect most people don't look at tasksel on a regular basis, but if it were possible to do a fresh woody install today, here is what you would see: An excellent summarisation, Joey: there is a problem here. Your suggestion is one way of looking at it, but is it the right way? I seem to never install using tasks because they are too general - they make decisions the way I wouldn't - and they are (at the same time!) too specific - they frequently make decisions I can make with dselect or apt-*. The idea of having tasks within tasks that someone suggested seems a good one though. If you could have a structure of tasks then you could have a top level task which selected (by default) the lower level ones, but still allowed override of lower level tasks. For example, you list Database Pg as one task. Much as I am a fan of PostgreSQL there are other choices, so it should really be Database Server, and it should default to being a PostgreSQL database server. The interface (blithely ignoring implementation details here!) could allow the user to track into Details and adjust things for different defaults. This is a very different way of looking at things than dselect does - much finer-grained, and much more functionally based than the dselect categorisations are. Lets face it, this is really more how dselect should be categorising things. What is the use of a loose categorisation such as 'net', 'web', 'X', 'mail' or 'games' (OK, well maybe 'games') apart from a really rough and ready guide to finding things. Some of these are narrow and some are huge. The sub-split by importance is irrelevant to most humans driving the interface now (but helpful to programs). TaskSel is a good idea: re-categorise things in a functional manner, but it doesn't go far enough. There need to be at least three levels available to such a hierarchy, but preferably there should be ten or more. Thanks for putting your proposal forward - I hope it's going to promote some really valuable discussion. Regards, Andrew. -- _ Andrew McMillan, e-mail: [EMAIL PROTECTED] Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Re: section 4.7.4 is poorly worded
Sean 'Shaleh' Perry wrote: quote 4.7.4 Sharing configuration files Packages that are not tagged as conflicting with each other must not specify the same file as conffile. /quote This is very poorly worded. The text used to read - quote Only packages that are tagged *conflicting* with each other may specify the same file as `conffile'. /quote Which makes a great deal more sense. Or what about: quote Packages which specify the same file as `conffile' must be tagged as *conflicting* with each other. /quote Which loses the double-negative, and retains the strong _must_ without becoming impenetrable. Regards, Andrew McMillan. -- _ Andrew McMillan, e-mail: [EMAIL PROTECTED] Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
