Bug#883950: Next steps on "[GPL-3+]" proposal
On Sat, Dec 30, 2017 at 01:26:29PM -0800, Russ Allbery wrote: > Julian Gilbey <jul...@d-and-j.net> writes: > > > Just a straw poll: who sees /etc/motd these days? My system (probably > > in common with many many users) boots into a graphical environment; I > > only see the motd in the case that I ssh into my machine. So I'm > > against removing the 'see /u/s/common-licenses' type wording in the > > copyright file, unless the copyright file is no longer intended for > > humans to be able to read and understand. > > Well, how many people ever look at /usr/share/doc//copyright, > though? I think it's reasonable to believe that if someone gets that far, > they've either seen /etc/motd or know enough about Debian to know where to > look for things. > > (I see it all the time, but I run Debian on servers.) Well, /usr/share/doc is a standard FHS location, /usr/share/common-licenses isn't, so I would think to look in /usr/share/doc for information about a package (and the first time I look there, I discover that Debian organises it by package). But I wouldn't think to look in /etc/motd to find out where license texts are stored - that's somewhat bizarre. I might look at the URL given at the top of the copyright file if I were really bothered to find out more about the format, but it still doesn't seem particularly arduous to continue to include the standard license conditions in the copyright file and a reference to /u/s/common-licenses: these files are generally created once and then updated only as necessary. Best wishes, Julian
Bug#883950: Next steps on "[GPL-3+]" proposal
On Fri, Dec 29, 2017 at 07:29:48PM -0800, Russ Allbery wrote: > I agree that we should probably add /usr/share/common-licenses to the > default motd. Currently, we say: > > The programs included with the Debian GNU/Linux system are free > software; the exact distribution terms for each program are described > in the individual files in /usr/share/doc/*/copyright. > > and could just add something like: > > The full texts of common licenses used by multiple packages can be > found in /usr/share/common-licenses. Just a straw poll: who sees /etc/motd these days? My system (probably in common with many many users) boots into a graphical environment; I only see the motd in the case that I ssh into my machine. So I'm against removing the 'see /u/s/common-licenses' type wording in the copyright file, unless the copyright file is no longer intended for humans to be able to read and understand. Best wishes, Julian
Bug#852542: Running initscripts: invoke-rc.d is now in an essential package
Package: debian-policy Version: 3.9.8.0 Severity: normal Tags: patch As invoke-rc.d is now (in stretch) in an essential package, I propose simplifying the script example in policy to remove the test for its existence (debhelper already does this): --- /tmp/policy.sgml.orig 2017-01-25 11:35:34.787735041 + +++ /tmp/policy.sgml2017-01-25 11:36:39.075433047 + @@ -7767,11 +7767,7 @@ action in their postinst and prerm scripts to: - if which invoke-rc.d >/dev/null 2>&1; then - invoke-rc.d package action - else - /etc/init.d/package action - fi + invoke-rc.d package action Best wishes, Julian -- System Information: Debian Release: 9.0 APT prefers jessie APT policy: (500, 'jessie'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.10.7 -- no debconf information --- /tmp/policy.sgml.orig 2017-01-25 11:35:34.787735041 + +++ /tmp/policy.sgml2017-01-25 11:36:39.075433047 + @@ -7767,11 +7767,7 @@ action in their postinst and prerm scripts to: - if which invoke-rc.d >/dev/null 2>&1; then - invoke-rc.d package action - else - /etc/init.d/package action - fi + invoke-rc.d package action
Obsolete file in debian-policy package
Hello! I propose that the 18-year-old file /usr/share/doc/debian-policy/libc6-migration.txt.gz shipped in the debian-policy package is dropped from future versions of debian-policy, as it serves no meaningful purpose nowadays, except possibly historical interest. (And for that, we have archives.) Julian
Bug#707851: Let's remove the Debian menu from the Debian Policy ?
On Sat, Jan 11, 2014 at 11:46:10AM +0900, Charles Plessy wrote: Hello everybody, I have read a lot of scepticism about the Debian menu in this thread, and no actual support for it. Perhaps I was trying to be too consensual and proposed an over-complicated solution while it is clear that the FreeDesktop system is superior. I attached a new patch, where the Debian menu is removed, and pasted below a text export of the 9.6 and 9.7 sections after application of the patch. Thanks, Charles! Could I humbly suggest that for a change as significant as this, it would be worth asking for feedback on debian-devel and debian-user as well? It could be that there are users who will be significantly affected by this but who don't read the -policy list. Then again, there may well be silence or approval from those lists too. Julian -- 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/20140112093832.gd13...@d-and-j.net
Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: Dear all, Based on Josselin's contribution and the comments of Russ, I have written a patch for the Debian Policy, that documents the use of the FreeDesktop standards for the use of Desktop menus and media types (MIME). Thanks, Charles, this reads really nicely. Disclaimer: I admit to having no particular expertise in this area, nor do I have any specific affiliations. I do not feel in a position to meaningfully second this proposal. One suggested rewording: 9.7. Multimedia handlers [...] Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. I suggest appending but not both to make it really explicit (I know it's mentioned later in one of the subsections, but there's no harm in repeating it): ... should register them using either the _FreeDesktop_ system or the _mailcap_ system, but not both. Julian -- 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/20140105084812.ga6...@d-and-j.net
Bug#731810: Please, do not advertise DEHS
On Mon, Dec 09, 2013 at 09:55:02PM -0400, David Prévot wrote: diff --git a/policy.sgml b/policy.sgml index dad8d23..4eb55d9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2367,8 +2367,7 @@ endif This is an optional, recommended configuration file for the ttuscan/tt utility which defines how to automatically scan ftp or http sites for newly available updates of the - package. This is used - by url id=http://dehs.alioth.debian.org/; and other Debian QA + package. This is used Debian QA tools to help with quality control and maintenance of the distribution as a whole. /p s/This is used Debian/This is used by Debian/ Seconded. Julian signature.asc Description: Digital signature
Re: Removing obsolete configuration files on upgrade
On Sat, Nov 30, 2013 at 12:03:53PM -0800, Jonathan Nieder wrote: My hunch is to say that a package may remove /etc/greeting in this case but by no means should. That is, something like the following but hopefully less awkward: Obsolete configuration files without local changes may be removed by the package during upgrade, and should be removed by the package during upgrade from the version before they were obsolete. What do you think? What does upgrade from the version before they were obsolete mean? Does this mean the stable version before they were obsolete? Or any version before they were obsolete? Perhaps during upgrade from a version before they were obsolete would be better? More significantly, how does this suggestion help in your case? It doesn't seem to mention it; it only mentions the regular case. Julian -- 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/20131130201343.ga7...@d-and-j.net
Bug#728200: debian-policy: force build tools to ensure source trees are build-ready
On Tue, Oct 29, 2013 at 01:25:57PM +, Ximin Luo wrote: Not having to support patch greatly simplifies things, but deprecation is not mentioned anywhere in Section 4... Do you know how many existing packages still use patch? That's a good point: with the not-so-recent introduction of the recommended source format 3.0 (quilt) for non-native packages, there should probably be two changes: * In section 4.9, the `patch' target should be labelled as (deprecated) instead of (optional), and the wording of the paragraph updated to something like: This now-deprecated optional target performs whatever additional actions are required to make the source ready for editing (unpacking additional upstream archives, applying patches, etc.). It was previously recommended to be implemented for any package where `dpkg-source -x' does not result in source ready for additional modification. However, when using source format 3.0 (quilt), all of this is now done automatically by `dpkg-source -x', so there should be no need for a separate `patch' target. Also see Section 4.14, `Source package handling: `debian/README.source''. * In section 4.14, the opening part could be reworded as follows. Note also a clarification to the wording of point 3 below: In general, when using source format 3.0 (quilt) or later, running `dpkg-source -x' on a source package will produce the source of the package, ready for editing. This will allow one to make changes and run `dpkg-buildpackage' to produce a modified package without taking any additional steps. (Note, however, that such modifications must be made in the form of a new patch using the `quilt' system with QUILT_PATCHES=debian/patches, otherwise `dpkg-source -b' will fail.) If other steps are required to produce a source package ready for editing, creating a `debian/README.source' documentation file is recommended. This file should explain how to do all of the following: 1. Generate the fully patched source, in a form ready for editing, that would be built to create Debian packages. In general, this should be automatically achieved by running `dpkg-source -x', but if not, this should be documented. There used to be an optional `patch' target in `debian/rules' for this purpose; see Section 4.9, `Main building script: `debian/rules''. 2. Modify the source and save those modifications so that they will be applied when building the package. 3. Remove source modifications that are currently being applied. 4. Optionally, document what steps are necessary to upgrade the Debian source package to a new upstream version, if applicable. Julian -- 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/20131029153830.ga20...@d-and-j.net
Re: Roadmap to version 3.9.5 or 4.0.0 ?
On Sat, Aug 10, 2013 at 01:55:38PM +0900, Charles Plessy wrote: [...] In terms of quantity of work, I think that the documentation of the triggers is almost done. This said, the loud silence makes me feel that this work is very controversal, so I am not sure if it will be part of the Policy anytime soon. Either controversial, or alternatively, that people are happy with what has been said. Here are possible directions for our future work. 1) Release 3.9.5 as it is, convert to XML as 4.0.0, and resume the normative work. 2) Same as 1) but skip 3.9.5. 3) Same as 1) or 2), but close a bunch of low-hanging fruits first. 4) Work on multi-arch first. What do you think ? Do you have other propositions ? I don't have a strong opinion, except to suggest doing whichever route will cause you the least amount of effort makes the most sense. A number of years ago, when I was very active on the Policy Group, I proposed transitioning the policy's use of the terms SHOULD, MUST, etc. towards the meanings of those words as they are used in the IETF RFCs. I also proposed restructuring the policy document, as it had become somewhat disorganised over the years. I (sadly) do not have time nowadays to be involved in this, but I offer it as a proposal to reconsider now during such a major piece of work as this. Good luck, and thanks for your work! Julian -- 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/20130810212144.ga23...@d-and-j.net
Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
On Sun, Apr 14, 2013 at 06:01:10PM +0900, Charles Plessy wrote: Le Mon, Apr 08, 2013 at 12:18:37AM +0100, Julian Gilbey a écrit : For consistency, I guess this should be /usr/games rather than /usr/games/. The final paragraph seems a little bit vague; would should be restricted to ASCII when it is possible to do so be clearer? For if Unicode characters can be represented in ASCII, they almost always would be. This alternative wording would suggest that using characters such as em-dashes or non-breaking spaces or the like is not good (though I doubt people would use them as filenames of packaged files!). Thanks everybody for the feedback. I am ready to commit the patch, updated following Julian's suggestions. But strictly speaking, I need one more formal seconding statement for this :) I'm happy to second the proposal. Julian -- 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/20130414094056.gb23...@d-and-j.net
Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
On Sat, Apr 06, 2013 at 08:20:15PM +0900, Charles Plessy wrote: Here is a somewhat clumsy proposition. sec id=filenames headingFile names/heading p The name of the files installed by binary packages in the system PATH (namely tt/bin/tt, tt/sbin/tt, tt/usr/bin/tt, tt/usr/sbin/tt and tt/usr/games//tt) must be encoded in ASCII. /p For consistency, I guess this should be /usr/games rather than /usr/games/. p The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when they can be represented in that character set. /p /sec What do you think ? That sounds a very reasonable proposal. The final paragraph seems a little bit vague; would should be restricted to ASCII when it is possible to do so be clearer? For if Unicode characters can be represented in ASCII, they almost always would be. This alternative wording would suggest that using characters such as em-dashes or non-breaking spaces or the like is not good (though I doubt people would use them as filenames of packaged files!). Julian -- 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/20130407231837.ga9...@d-and-j.net
Re: [proposal] remove the requirement to compress documentation
On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote: As such, I believe the requirement to compress files is an anachronism that we should get rid of. I do not like removing a useful requirement in exchange for nothing. Debian is used on small systems where users still like to have documentation, and support zlib compression is almost universal. Every Debian stable release has higher diskspace requirement than the previous one already. Why make it even bigger ? texdoc generally fails on .pdf.gz files, but I guess that application could be fixed instead. Julian -- 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/20120220180050.ga6...@d-and-j.net
Bug#660193: developers-reference: please suggest debian/rules target name for preparing source
On Fri, Feb 17, 2012 at 11:14:00AM +0100, Carsten Hey wrote: Package: developers-reference Severity: wishlist Maintainers might decide to add a special make target to prepare the source tree for building, i.e., that make target is run by the maintainer after a VCS checkout and possibly before releasing new versions. Possible reasons for this include reducing build dependencies and ensuring that specific files are equal on different architectures. Due to multi-arch, implementing such a target becomes more interesting. Although I do not expect this to be used widely, I think the developers reference should suggest a name for this target to archive consistency. The package debianutils already uses such a target and uses 'prebuild' as name. The developers reference could adopt this name. How would this relate to Policy 4.14 - debian/README.source? Julian -- 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/20120217122801.ga20...@d-and-j.net
Bug#660193: developers-reference: please suggest debian/rules target name for preparing source
On Fri, Feb 17, 2012 at 02:46:15PM +0100, Carsten Hey wrote: How would this relate to Policy 4.14 - debian/README.source? [...] The intention of this bug report is to unify the name of a target that might be used more often soon, and it is not sufficient to reach this goal if we rely on package maintainers to document the target they use in debian/README.source. I hope this answers your question (I'm not sure which relation you meant exactly). That makes a lot of sense, thanks! Julian -- 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/20120217152928.ga24...@d-and-j.net
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
On Thu, Oct 27, 2011 at 11:18:53AM +0200, Bernhard R. Link wrote: If you wanted to replace policy with a formal set of requirements and descriptions like RFCs have them, then this argument could hold. Is not policy mainly trying to do precisely this? If not, then what is its purpose? But transforming policy into this is illusory and I doubt it would benefit much. It's a mixture of descriptions, requirements and rationals. Each of them living on one of many different levels (while generally rather describing the higher levels, leaving lower level stuff to the implementation (i.e. dpkg and dak). It's a set of rules to be used on top of the implementation to allow us to build a coherent system. Indeed, and RFCs are similar. Just take a look at the section Binary packages and notice what is not described in there. (And for people suggesting to use some RFC like description and thinking that is possible, what would you make out of the current 3.1, 3.2, and 3.2.1 for example?) 3.1: First paragraph becomes: Each package has a name; this name MUST be unique within the Debian archive. The second paragraph is unchanged. 3.2: Unchanged, except in final paragraph where should be converted is changed to SHOULD be converted. 3.2.1: All three paragraphs, capitalise the first occurrence of the word should. A good portion of this is descriptive, and that is fine, but there are a few prescriptive parts, and they should have capitalised words. I don't seem to understand the difficulty you are pointing out - please could you clarify? Julian -- 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/20111027095130.ga20...@d-and-j.net
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
BOn Thu, Oct 27, 2011 at 03:11:14PM +0200, Bernhard R. Link wrote: 1;2801;0c * Julian Gilbey jul...@d-and-j.net [111027 12:09]: 3.2: Unchanged, So a package without a version is fine? except in final paragraph where should be converted is changed to SHOULD be converted. So you suggest to change policy so that this is no longer a bug if not done? An interesting point. Section 5.3 states that 'Version' is mandatory in DEBIAN/control; 5.4 that it is mandatory in .dsc, 5.5 that it is mandatory in .changes. So it follows that every package MUST have a version number. The way policy is currently written is that the first paragraph of 3.2 is descriptive only. It certainly could be rewritten to say Every package MUST have a version number recorded in its 'Version' control file field..., but I think the descriptive text works better at this point, as the control file has not yet been described. (I don't think that Policy explicitly states that the version numbers in these different fields must be identical, but then again, Policy was designed for the humans writing packages. There will almost certainly always be such gaps, and it is unclear whether they need filling.) Converting Policy to use the RFC terms will most likely not be error-free, but it will make things a lot easier to follow, and I believe it will be a significant improvement for the reasons already discussed. Policy will never have the watertightness of an RFC, but that is not its purpose. Julian -- 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/20111027163534.ga18...@d-and-j.net
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
On Tue, Oct 25, 2011 at 03:43:26PM -0700, Russ Allbery wrote: I think it would be lovely to just use RFC 2119 language or a close adaptation thereof. We're sort of reinventing the wheel here, and we're not doing a very good job of it in terms of consistency and shared understanding of the terms. RFC 2119 solves the problem of indicating that these words have specific meanings by putting them in all caps when they're used with specific definitions. Doing the conversion in all of Policy would be a ton of work, though. When I was on the policy team, I strongly advocated this and offered to do the work. It was not taken up at the time, but I am still strongly in favour of such a move: many people reading Debian Policy will be familiar with RFCs and their precise use of the RFC 2119 terms; having Debian Policy following the same terminology (ideally also capitalised in the same way) would be fantastic. The amount of work necessary is probably not as great as you fear, though. It will require some judgement calls, but that just highlights the imprecision in places in current policy. One issue which was raised way back when was that a violating a Policy MUST or MUST NOT may not necessarily produce an RC bug - what is considered an RC bug is the preserve of the Release Managers. But that should not stop Policy from using such terms; packages which do not follow such directives are buggy, even if they are temporarily condoned by the RMs. Julian -- 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/20111027003316.ga9...@d-and-j.net
Bug#610083: Remove requirement to document upstream source location in debian/copyright ?
On Sun, Jan 16, 2011 at 03:31:41AM +0100, gregor herrmann wrote: What is boring (like for all CPAN modules) is to have the very same information in 3 places (copyright, control, watch), therefore I'd support a change like you sketched above (may be skipped if Homepage is clear enough) or maybe also if uscan just works and d/watch is sufficiently clear (not a proper wording for Policy but as a rough idea). Not the latter please: it is not useful if you only have the binary package installed but not the source. Julian -- 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/20110116081406.ga32...@master.debian.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, Jun 04, 2009 at 10:16:06PM +0100, Adam D. Barratt wrote: So printf is slightly unwiedly to use and it can create format string attack. It does, however, have the advantage of working if BAR contains -E. (This isn't a contrived example, it's why I recently changed the parsing of DEBUILD_LINTIAN_OPTS to use printf rather than echo; if there's a sane way of printing -E using echo I'd love to know what it is). Not quite correct, but echo -E does print -E Julian -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473439: pick consistent terminology for category/component/area
On Sun, Jan 25, 2009 at 03:37:37PM -0800, Russ Allbery wrote: Russ Allbery r...@debian.org writes: I did a bit more research based on Osamu Aoki's excellent work. Currently, these things are referred to using three different terms: [...] As mentioned, I'm not sure we need to match the terminology in dak as long as we're not confusing about it. dak is referring to technical capabilities which are used to implement certain features. I still think distribution area is a good name for this, better than categories. [...] Here's the proposed patch: diff --git a/policy.sgml b/policy.sgml index 24c9072..16919b2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -293,7 +293,13 @@ emfree/em in our sense (see the Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split into the distribution - areas or categories based on their licenses and other restrictions. + areas or componentsfootnote + The Debian archive software uses the term component internally + and in the Release file format to refer to the division of an + archive. The Debian Social Contract refers to distribution + areas. This document uses the same terminology as the Social + Contract. + /footnote based on their licenses and other restrictions. /p p @@ -310,8 +316,8 @@ /p p - The emmain/em category forms the - emDebian GNU/Linux distribution/em. + The emmain/em distribution area forms the emDebian GNU/Linux + distribution/em. /p p @@ -422,10 +428,10 @@ /sect sect id=sections - headingCategories/heading + headingDistribution areas/heading sect1 id=main - headingThe main category/heading + headingThe main distribution area/heading p Every package in emmain/em must comply with the DFSG @@ -456,7 +462,7 @@ /sect1 sect1 id=contrib - headingThe contrib category/heading + headingThe contrib distribution area/heading p Every package in emcontrib/em must comply with the DFSG. @@ -496,7 +502,7 @@ /sect1 sect1 id=non-free - headingThe non-free category/heading + headingThe non-free distribution area/heading p Packages must be placed in emnon-free/em if they are @@ -612,13 +618,13 @@ headingSections/heading p - The packages in the categories emmain/em, + The packages in the distribution areas emmain/em, emcontrib/em and emnon-free/em are grouped further into emsections/em to simplify handling. /p p - The category and section for each package should be + The distribution area and section for each package should be specified in the package's ttSection/tt control record (see ref id=f-Section). However, the maintainer of the Debian archive may override this selection to ensure the @@ -627,10 +633,10 @@ list compact=compact item emsection/em if the package is in the - emmain/em category, + emmain/em distribution area, /item item - emsegment/section/em if the package is in + emarea/section/em if the package is in the emcontrib/em or emnon-free/em distribution areas. /item @@ -8949,9 +8955,10 @@ install-info --quiet --remove /usr/share/info/foobar.info /p p - Packages in the emcontrib/em or emnon-free/em categories - should state in the copyright file that the package is not part - of the Debian GNU/Linux distribution and briefly explain why. + Packages in the emcontrib/em or emnon-free/em + distribution areas should state in the copyright file that the + package is not part of the Debian GNU/Linux distribution and + briefly explain why. /p p Seconded. Julian signature.asc Description: Digital signature
Re: Stepping down from Policy team
On Tue, Dec 23, 2008 at 11:31:41PM -0600, Manoj Srivastava wrote: Again, I thank all the folks who have been involved in Debian technical policy development over the years, I think the technical policy is one of the best things about Debian. It has been wonderful working with all y'all. Likewise - while we had our disagreements about the direction of policy many moons ago, I never doubted your technical expertise or your level of commitment to the project, and I am pleased that our debates always remained entirely technical and non-personal. Manoj, we are sorry to lose you, and thank you for your immense contributions to the project. Julian -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Phoning home
On Sun, Feb 24, 2008 at 01:54:11PM +, Ian Jackson wrote: I think therefore that we should add some statement to policy about phoning home. Agreed. As a starting point: * Software in Debian should not communicate over the network except - in order to, and as necessary to, perform their function (which includes the established Debian software update distribution infrastructure); or I'm not sure what the phrase in parentheses means. - for other purposes with explicit permission from the user So what about visiting a website with a browser which then opens a popup? Not sure how best to word this, but I fundamentally agree with the sentiment. * When Debian software is talks to a central server, whether to perform its core function (eg, an ntp client talking to ntp servers), or for other purposes with permission (like collection of usage information), the servers should be chosen and managed in a way that gives maximum regard to the users' privacy. In particular, - Usually, our software should communicate only to servers we control or which we have substantial reason to trust. By default, our software should ... The user might be given an option to change this (see below). - The information which is transmitted, and the information store those servers, should be limited to that necessary for the purposes in question. It would be nice to allow users to choose to report to meshlab upstream the statistical information which meshlab upstream would like to collect about the data files users are processing. At the moment we have only the single question about popcon. Should we have a separate question about each package like meshlab ? How often is this going to arise ? We could have one question which asks Some software authors like collecting anonymised data about the usage of their software in order to better optimise it. Would you be willing to participate in this?, and then the possibility of opting in/out of individual packages. Also, any package which does something essentially different could have its own question. I think from the pov of meshlab, it would be good to be able to anonymise and aggregate the information on Debian servers before reporting it upstream. What do people think about some kind of package-specific ad-hoc laundering service, or a popcon addon ? This could be an option given to the user, I guess. I like the possibility of anonymising responses, as long as it does not negatively affect the benefits the phoning home provides. (For example, it could be that upstream wants to know about the habits of individual users and their patterns over time rather than just the sum total of this information. In such a case, Debian would have to track the individual users, then modify the info before sending it upstream.) Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The case for rewriting the Policy document (Debconf7 proposal)
On Sun, Jul 15, 2007 at 09:38:53AM -0500, Manoj Srivastava wrote: Hi folks, This proposal is based on part of a talk I gave at debconf7, and is about reorganizing the policy document(s). The current policy document grew organically from the dpkg documentation, and the packaging manual, and has grown bloated, and contains material that does not sanely belong in policy. Policy needs to come closer to release goals. We really should not need a release team RC criteria list. Yes, yes, yes!!! This is a great idea! And let's have a consistent meaning for MUST/SHOULD/MAY (ideally, one which parallels the RFC usage for simplicity): MUST is RC if it's not done, SHOULD - hmm, is this RC or not? Could have two meanings: RC if not done, unless there's an exceptional reason not to conform, or Will be RC in the future, so get ready! Perhaps we could disambiguate these two possibilities? Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Add Debian revision number standards to policy?
On Thu, Nov 03, 2005 at 01:01:22AM -0200, Henrique de Moraes Holschuh wrote: On Tue, 01 Nov 2005, Nathanael Nerode wrote: I was surprised to discover that the standard rules for Debian revision numbers (maintainer revisions contain no dots; source NMUs contain one dots; binary NMUs contain two) are not in Policy, but only in the Developer's Reference. They are not even where they need to be toolwise, binary NMUs break strict versioned dependencies hideously... Should a policy patch be created? IMHO, Yes. IMHO you should also add that you are only to use numbers without zero padding (not that the tools will break if you pad, AFAIK, but...), that they must increase monotonically, that NMUs start with 1 and binary NMUs start with 0.1 if there isn't a NMU version yet, or NMU.1 if there is one. I presume you mean: they should go up by one each version. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333862: debian-policy: Policy forbids account creation
On Fri, Oct 14, 2005 at 08:46:57PM +1000, Ben Finney wrote: The section in the policy should say Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow directly from their maintainer scripts. I'd suggest: Maintainer scripts for packages must not modify any of /etc/passwd, insert directly here /etc/shadow, /etc/group or /etc/shadow, with the sole exception of the base-passwd package. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314808: Incorrect directory for web applications.
On Mon, Jun 20, 2005 at 12:03:01AM +0200, Miguel Gea Milvaques wrote: Also, as this is a draft, the useage of /usr/share/PACKAGE/www may change. IMO, it's probably not going to, but it may be worth keeping (main) policy as is until we are in a position to release 1.0 of the WebApps policy. No problem for me. But It could give little problems. On one of my machines a was beholden to remove /usr/share/doc directory, it broke my ldap-account-manager installation. Note: /usr/share/PACKAGE/www, not /usr/share/doc/PACKAGE/www. Removing /usr/share/doc should not impact this web suggestion. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis wrote: I appreciate your efforts, but i'm sorry: i still have not seen a reply to last mail from Branden: Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Please could you provide references in the form of http://lists.debian.org/... so that we can track these down? Thanks, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Fri, Nov 14, 2003 at 01:49:19PM +0100, Bill Allombert wrote: I appreciate your efforts, but i'm sorry: i still have not seen a reply to last mail from Branden: Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Please could you provide references in the form of http://lists.debian.org/... so that we can track these down? Here it is: http://lists.debian.org/debian-policy/2003/debian-policy-200311/msg00092.html Note that http://lists.debian.org autmomatically add link to messages matching Message-ID. How? I haven't figured out how to search by Message-ID. However, Branden question belong more to debian-dpkg than here. In response to Branden's question (does debian/control already have to exist when the package is unpacked), I would suggest the following: Before debian/rules build* is run, one has to check the build-dependencies. So at this point, at least the source section of debian/control must exist. And since this field (whatever form it eventually takes) would exist in the source section of debian/control, and would not be needed until after the build-dependencies are checked, there should be no problem. And then again, we can always use debian/interfaces or debian/rules.targets or something similar instead Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote: On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote: 3.1) Provide an easy and reliable way to tell if the optional targets are implemented. And once that's there, clarify Policy to say what dpkg-buildpackage et al will do: if optional targets are missing, do the old thing. If the optional targets are there, do the new thing instead. No, can't do that! There is no way to test for the presence of optional targets! (That's why this whole proposal was suggested.) So it would be something like: rules-version=0 required targets: build, binary-arch, binary-indep, binary, clean rules-version=1 additional required targets: build-arch, build-indep rules-version=2 additional required targets: ... etc. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote: On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote: 3.1) Provide an easy and reliable way to tell if the optional targets are implemented. And once that's there, clarify Policy to say what dpkg-buildpackage et al will do: if optional targets are missing, do the old thing. If the optional targets are there, do the new thing instead. Oh, I just misparsed this when I replied last time. I think what you mean is: if rules.version=0, then dpkg-buildpackage behaviour will be ... if rules.version=1, then dpkg-buildpackage will be allowed to do ... etc. But of course, this has to be done with the consent and coorperation of the dpkg maintainers. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Thu, Oct 23, 2003 at 12:58:19AM +0200, Bill Allombert wrote: So I come up with a different proposal: Introducing a new file, say debian/rules.version. If this file does not exist, we declare that version=0, else version=`cat debian/rules.version`. Yes, yes, yes! What an elegant solution to such a messy problem. Well done! You certainly have my vote!! Currently 2 versions are defined: 0: debian/rules support rules described as mandatory by policy. 1: as 0, but debian/rules also support build-arch and build-indep. Future version of policy can define higher version. dpkg-buildpackage just need to read this file before deciding whether it can call debian/rules build-arch. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: testing packages at build-time
On Fri, Oct 10, 2003 at 01:41:42AM +0200, Matthias Urlichs wrote: 2?) We add a test target in debian/rules. Autobuilders will need to be modified to take advantage of this. We can then go farther and implement special testing facility. How would you distinguish a failed test from a debian/rules file which doesn't have a test target? debian/rules -q test Then test the value of $? (info make for more information) This, of course, assumes that debian/rules has to be a makefile. (I'm sure this is flamebait, but it makes a lot of logistical sense.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#206928: LSB vs. Policy
On Sun, Aug 24, 2003 at 12:09:14PM +0200, Martin Godisch wrote: See subject. The init script should just be quiet, as other init scripts do. Instead, it says ...program not found. This is in compliance with the Linux Standard Base: In case of an error, while processing any init script action except for status, the init script must print an error message and return one of the following non-zero exit status codes. 5 - program is not installed http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html I do not care much about LSB when it specifies bull^h^h^h^h weird things - and in this case, it clashes with our Policy (?9.3.2). ignorance I thought that the LSB only applies to LSB packages and Debian Policy applies to Debian packages. In this case, we have this graceful exit clause so that when a package is removed but not purged, the script exits silently. I don't know whether LSB packages have such a concept (removal vs. purge). /ignorance Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: for i in /usr/bin/foo /usr/sbin/bar do if ! dpkg-statoverride --list $i /dev/null then dpkg-statoverride --update --add sysuser root 4755 $i fi done The corresponding dpkg-statoverride --remove calls can then be made unconditionally when the package is purged. This means that the files are unpacked with whatever permissions were in the package, and are then modified during postinst. In addition, if the sysadmin removes the statoverride entry, the postinst will blindly add it back again later. Another possibility then is to do the following. Firstly, ensure that the default owner/group and permissions in the .deb are safe, and that if the package breaks because of them, it will do so in a safe way (the meaning of this will depend on the package). No-one expects an unconfigured package to necessarily work (with exceptions for essential packages, but we can ignore those here). Then change the line in the postinst: + if [ $1 = configure ] + then for i in /usr/bin/foo /usr/sbin/bar do - if ! dpkg-statoverride --list $i /dev/null + if [ dpkg --compare-versions $2 lt 2.3.4-2 ] then dpkg-statoverride --update --add sysuser root 4755 $i fi done + fi where 2.3.4-2 is to be replaced by the first version in which this statoverride was introduced. In this way, if the sysadmin later touches the statoverride, their changes will remain (for good or bad). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target
On Mon, Jun 09, 2003 at 01:09:48PM +0100, Andrew Suffield wrote: However, regardless of what policy says, those packages are broken anyway. If you don't have debhelper installed, and you run dpkg-buildpackage -rfakeroot -us -uc -b, it'll fail. This bug is not important because there's no real reason to run that command on an arch-indep package. Yes, it may well do. It depends upon whether the rules file has been correctly written to not require the arch-independent build-dependencies for the binary-arch target (probably by using build-arch and build-indep targets). As has been explained, the problem is somewhat academic, though. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Sun, Apr 06, 2003 at 09:40:59PM -0400, Peter S Galbraith wrote: 6 weeks ago, Julian Gilbey [EMAIL PROTECTED] wrote: As things stand with the buildds, the -Indep fields are almost useless, and it may actually be worth dumping the -Indep field altogether. tomcat, tomcat4, bigloo, bochs, dutch, gcc-avr, grub-installer, gstreamer, httrack, hylafax, latex2rtf, libgcrypt, libgnome, libgnomecanvas, libgnomeprintui, libgnomeui, librep, libwnck, lilypond, ncbi-tools6, plex86, remstats, sawfish, sysstat, yaboot-installer are the only packages in sid which are not Architecture: all and which have a Build-Depends-Indep field. gri has had it for a long time. Oops; my script was buggy. There are at least 95 packages in sid/main which satisfy this criterion. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#184368: sematic error, 2.3.1 The package name
On Tue, Mar 11, 2003 at 07:48:11PM -0800, Osamu Aoki wrote: On Tue, Mar 11, 2003 at 03:57:07PM -0600, Drew Scott Daniels wrote: Package: debian-policy Section 2.3.1 says: Package names must consist of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). It should say something like: Package names must not consist of anything other than lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). because it is not desirable, and not the current convention to make packages contain all of the items in the list. eg why force apt to have digits, plus and minus signs and periods. It would have to have a name like apt00+-.. to be valid. Please do not push pedantic argument too much :-) Double negative expressions are error prone and difficult to understand for non-native speakers. I think it is fine as is since the original text uses consist of instead of contain. How about: Package names must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). inserting the word only? BTW, I have never seen any package name starting any of +, -, or ., nor I have seen any package name with repeated .. I guess common sense rules. Policy 2.3.1: must begin with an alphanumeric. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: policy should get released
On Mon, Feb 24, 2003 at 07:17:02PM +0100, Josip Rodin wrote: Hi, Policy 3.5.9 is more or less ready for release as far as I'm concerned. By my last count, it fixes 17 different bugs from the BTS, and adds four relatively minor items to the upgrading checklist. Since I'm a newbie policy editor, I'd appreciate if others would go through the changes and verify that they're all right. I'd also need to get another 6/24 MB worth of build-dependencies in order to build the package (wretched FHS...), so my poor ol' modem would appreciate if someone else did that for me. :) Manoj has told me he won't be available in the near future. Julian? Branden? Next week. Please email me to remind me then! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Fri, Feb 14, 2003 at 12:23:50AM -0600, Adam Heath wrote: On Tue, 11 Feb 2003, Julian Gilbey wrote: So given how few packages we are talking about, would it be worth the buildds using all packages specified in both Build-Depends and Build-Depends-Indep and phasing out Build-Depends-Indep? I modified apt's build earlier this week to work in split mode. I'll also be making certain dpkg does as well. Please don't phase it out. Great! What do you mean by split mode, though, and does this mean that we must have something like debian/rules -q build-arch returning a meaningful value? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Tue, Feb 18, 2003 at 12:20:49PM -0600, Adam Heath wrote: Great! What do you mean by split mode, though, and does this mean that we must have something like debian/rules -q build-arch returning a meaningful value? No, it means that build-indep is built during the binary-indep rule(which build deps on). binary: binary-arch binary-indep binary-arch: apt libapt-pkg-dev apt-utils binary-indep: apt-doc libapt-pkg-doc apt: build libapt-pkg-dev: build apt-utils: build apt-doc: build-doc libapt-pkg-doc: build-doc But if you have a Build-Depends-Indep field containing packages which are needed for the build-indep target, then the autobuilders will fail, as they first run the build target and then the binary-arch target. So unless dpkg and the autobuilders are going to consider changing to support the originally-intended setup, there is no point maintaining this distinction in policy. Of course, there is no problem with individual packages doing this; it causes no harm. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Tue, Feb 11, 2003 at 06:55:37PM +, James Troup wrote: Julian Gilbey [EMAIL PROTECTED] writes: In that case, the buildds are broken: they don't install Build-Depends-Indep, even though they do invoke the clean and build targets of debian/rules (through dpkg-buildpackage). See http://buildd.debian.org/fetch.php?pkg=freesciver=0.3.4a-2arch=alphastamp=1043707174file=logas=raw for an example of this. Correct. No, it's not correct. The buildds are not broken, they're doing exactly what they've always done; you can't change policy and then declare that the buildds are broken because they don't follow how you've changed policy. Policy reflects current practice, remember? I guess you're right. These packages will have to have workarounds for the time being. The original intention of the whole -Indep split was incorrectly described first time around in policy, and the buildds dutifully followed the broken policy proposal. As things stand with the buildds, the -Indep fields are almost useless, and it may actually be worth dumping the -Indep field altogether. tomcat, tomcat4, bigloo, bochs, dutch, gcc-avr, grub-installer, gstreamer, httrack, hylafax, latex2rtf, libgcrypt, libgnome, libgnomecanvas, libgnomeprintui, libgnomeui, librep, libwnck, lilypond, ncbi-tools6, plex86, remstats, sawfish, sysstat, yaboot-installer are the only packages in sid which are not Architecture: all and which have a Build-Depends-Indep field. Of these packages, many simply repeat certain Build-Depends packages in the Build-Depends-Indep field, so don't need the field at all. A few others are probably broken with the current buildd *and* policy semantics (they are building for a single architecture but using Build-Depends-Indep). A few are probably legal according to current policy but broken for the current buildds. So given how few packages we are talking about, would it be worth the buildds using all packages specified in both Build-Depends and Build-Depends-Indep and phasing out Build-Depends-Indep? Another possibility is to modify the policy again to explain what the buildds currently do and to stick with that. Yet another possibility is to modify the buildds in the medium - long term to do something like the following: install Build-Depends test whether debian/rules build-arch is a legal target (using -q option, I think it is, assuming that debian/rules is a Makefile) if so, run it, otherwise install Build-Depends-Indep and run debian/rules build. Of course, such an elaborate scheme is only needed if the package has both Build-Depends and Build-Depends-Indep. (Incidentally, console-cyrillic is the only Architecture: all package to have both.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: mailing lists as maintainer address
On Wed, Feb 05, 2003 at 02:46:27PM +1100, Anand Kumria wrote: What is the opinion of this group? Anand As Joey pointed out, but with one addition: Source: debian-policy Section: doc Priority: optional Maintainer: Debian Policy List debian-policy@lists.debian.org Uploaders: Julian Gilbey [EMAIL PROTECTED], Manoj Srivastava [EMAIL PROTECTED] Note the Uploaders: field for the purposes of katie distinguishing between maintainer and non-maintainer uploads. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Wed, Jan 29, 2003 at 12:28:17AM +0100, Bas Zoetekouw wrote:
Hi Julian!
You wrote:
No: if binary-arch depends (in a Makefile sense) on build, then you're
not actually invoking build, and your make can do what it likes, as
long as you only need the Build-Depends packages. If you make build,
then you should require both Build-Depends and Build-Depends-Indep. I
know that's not what the autobuilders yet do, but one day they might
check for the existence of the build-arch target, and fall back to a
build target if that doesn't exist. At that point, the distinction
will make sense; the way the Build-Depends{,-Indep} fields were
originally designed or implemented was fundamentally broken, in that
the -Indep fields were useless.
In that case, the buildds are broken: they don't install
Build-Depends-Indep, even though they do invoke the clean and build
targets of debian/rules (through dpkg-buildpackage). See
http://buildd.debian.org/fetch.php?pkg=freesciver=0.3.4a-2arch=alphastamp=1043707174file=logas=raw
for an example of this.
Correct.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, website: http://www.polya.uklinux.net/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Tue, Jan 28, 2003 at 08:11:34PM +0100, Bas Zoetekouw wrote:
Package: debian-policy
Version: 3.5.8.0
Severity: important
Currently, policy says that following about Build-Depends-Indep (section
7.6):
| The Build-Depends-Indep and Build-Conflicts-Indep fields must be
| satisfied when any of the following targets is invoked: build, clean,
| build-indep, binary and binary-indep.
This makes no sense, because it would mean that Build-Depends-Indep
dependencies would have to be installed anyway (for clean target for
example) even when building only the arch-dependent binary packages.
Sorry, it is correct. See the footnote to that section. If you're
building the arch-dependent binary packages using binary-arch, then
you don't need the Build-Depends-Indep packages, and if you do, then
you have a FTBFS serious bug.
| ifvoid The Build-Depends-Indep and Build-Conflicts-Indep fields must
|be satisfied when any of the following targets is invoked: build,
|clean, build-indep, binary and binary-indep.
| ifvoid note that that includes build
Correct.
| elmo policy is broken
| BenC way broken
| ifvoid ok
| BenC that's just stupid
| BenC that pretty much says that indep needs to always be satisfied,
|which makes indep useless
No: if binary-arch depends (in a Makefile sense) on build, then you're
not actually invoking build, and your make can do what it likes, as
long as you only need the Build-Depends packages. If you make build,
then you should require both Build-Depends and Build-Depends-Indep. I
know that's not what the autobuilders yet do, but one day they might
check for the existence of the build-arch target, and fall back to a
build target if that doesn't exist. At that point, the distinction
will make sense; the way the Build-Depends{,-Indep} fields were
originally designed or implemented was fundamentally broken, in that
the -Indep fields were useless.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, website: http://www.polya.uklinux.net/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
Re: web browser url viewing proposal
On Wed, Dec 11, 2002 at 10:27:48AM -0500, Clint Adams wrote: that program may be configured to use /usr/bin/sensible-www-browser Inconsistency that should probably be fixed before going into Policy. How is this inconsistent? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 12:34:17AM +0100, Denis Barbier wrote: On Mon, Dec 09, 2002 at 11:28:46PM +, Julian Gilbey wrote: [...] I doubt that translators will need to extract such information in an automatic manner. If these informations were available, http://www.debian.org/intl/l10n/po/lang/ could point to CVS files instead of released ones. And as explained in a previous post, Debian translators could also skip GNU, GNOME and KDE packages (amongst others) which have their own l10n teams. At present, I am still quite sceptical that there are that many packages/sites which could be automated in this way to point to appropriate CVS files. What would probably make sense is for there to be an organised or even automated way for the debian l10n links to be set up for such packages without there needing to be data added to the control file. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 11:49:55PM +0100, Denis Barbier wrote: On Mon, Dec 09, 2002 at 04:30:30PM -0600, Adam DiCarlo wrote: [...] I don't think think this level of information for developers/contributors is appropriate for debian/control and pkg info. It's audience is too limited for the amount of bloat this will add to the repository. If anything, you could dictate this could be suggested or required in a /usr/share/doc/pkg/README or README.Debian file? Putting it in a README file won't help, it can't be automatically extracted. The problem is that debian/control is the only file with a parsable format, maybe such infos could be added to another file, say debian/infos, in a standardized manner. I doubt that translators will need to extract such information in an automatic manner. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#171221: openmotif: openmotif is not a native package
On Mon, Dec 02, 2002 at 06:35:52PM +1100, Brendan O'Dea wrote: Personally I prefer to rename the upstream tarball to .orig.tar.gz so it is byte-for-byte identical (although this is technically violating current policy which requires it to unpack into a .orig directory). I don't see anywhere in policy which requires this. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#171221: openmotif: openmotif is not a native package
On Mon, Dec 02, 2002 at 11:09:33PM +1100, Brendan O'Dea wrote: On Mon, Dec 02, 2002 at 09:46:01AM +, Julian Gilbey wrote: On Mon, Dec 02, 2002 at 06:35:52PM +1100, Brendan O'Dea wrote: Personally I prefer to rename the upstream tarball to .orig.tar.gz so it is byte-for-byte identical (although this is technically violating current policy which requires it to unpack into a .orig directory). I don't see anywhere in policy which requires this. Well, perhaps not in policy proper but in the appendices to policy from the Packaging Manual--C.3. Source packages as archives: The tarfile unpacks into a directory `package-upstream-version.orig', and does not contain files anywhere other than in there or in its subdirectories. True, and I'm looking forward to one of us having time to take those parts of the packaging manual which are still relevant and integrating them in an appropriate way with policy to create a guidelines document, as has been talked about for a while now. In the process, this paragraph will be updated appropriately! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: web browser url viewing proposal
On Mon, Nov 18, 2002 at 07:38:22PM -0500, Joey Hess wrote: This proposal grows out of dissatisfaction with the hard-coded browser lists provided by various programs like xchat and urlview to run a browser displaying an url. Also a desire to do right the BROWSER environment variable ESR proposed at http://www.tuxedo.org/~esr/BROWSER/. Mostly because I never want to configure again in a program what web browser to use. Yes, yes, yes!!! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#167422: files in /usr/share should be world-readable
On Fri, Nov 08, 2002 at 09:15:09PM -0500, James R. Van Zandt wrote: However, I think substituting LOG=`tempfile -m 644` would introduce a security bug. How? Surely tempfile still creates the file securely, even when the mode is other than 600? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: TrueType fonts, Type1 fonts, X, and the FHS
Did anything ever come of this?
On Thu, Oct 18, 2001 at 10:23:01AM -0500, Branden Robinson wrote:
Hi guys,
Okay, I guess it's time things got straightened out with regards to
scalable fonts in Debian.
As you are all probably aware, there is no current Debian Policy governing
fonts other than fonts for X, and no Policy at all regarding TrueType
fonts.
Policy is already frozen for woody, but that doesn't mean we can't work
something out between ourselves, implement it now, and get a policy
proposal written up for inclusion later.
There are a few guiding principles that I think should be adhered to
when writing up a Debian Font Policy:
1) Fonts should go in an FHS-compatible location. This probably means
/usr/share/fonts, which some packages already use.
2) /usr/share/fonts should probably be broken into subdirectories
indicating the file format of the font. E.g.:
/usr/share/fonts/truetype
/usr/share/fonts/type1
Again, some packages already do this.
3) Per FHS, only static data should go into /usr/share. This is not an
appropriate place for fonts.dir files, because these can change. See
the Debian X Font policy.
4) A subdirectory of /usr/X11R6/lib/X11/fonts should be created and used
in the short run to make these fonts accessible to font rasterizers for
the X Window System. These directories should not contain fonts
themselves, but should contain symlinks on a per-file basis to, e.g.,
/usr/share/fonts/truetype/font.ttf
5) Again, /usr/X11R6/lib/X11/fonts/TrueType should NOT be a symlink to
/usr/share/fonts/truetype.
6) In the long run, /usr/X11R6/lib/fonts should become a symlink into
/var/lib, because the fonts.* are updated on font package installation
and removal.
As a practical matter, I propose:
1) To add /usr/X11R6/lib/X11/fonts/TrueType to dexconf-generated
XF86Config{,-4} files, to /etc/X11/fs/config, and to /etc/X11/XftConfig;
2) That maintainers of packages containing Type1, and TrueType fonts:
A) install them to /usr/share/fonts/{truetype,type1,type3} as
appropriate;
B) provide fonts.scale files per existing Debian X Font Policy;
C) symlink each individual font file (.pfa, .pfb, .afm, .ttf,
etc.) from /usr/X11R6/lib/X11/fonts/{Type1,TrueType} to
/usr/share/fonts/{truetype,type1};
D) invoke update-fonts-{alias,scale,dir} as prescribed in
existing Debian Policy.
For the time being, I propose that xfonts-scalable be grandfathered and
permitted to install files directly into /usr/X11R6/lib/X11/fonts/Type1,
though I may go ahead and change this before woody releases if testing
demonstrates that I can do it without breaking anything.
Is there anything I'm missing? Any comments on the above?
--
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying
Re: Bug#161455: debian-policy: reference to ash outdated
On Thu, Sep 26, 2002 at 08:15:58AM -0400, Anthony DeRobertis wrote: On Fri, 2002-09-20 at 05:28, Julian Gilbey wrote: Technical problems here. Among other things, you'd have symlinks /bin/sh - /etc/alternatives/sh - /bin/something What happens if /etc is corrupted or not mounted or there are other problems? Nothing worse than what happens if you put /etc on a filesystem other than / without some pretty evil kluges... (hint: /etc/fstab) True ;-) Also, there is another major problem with using update-alternatives: we must *always* have a working /bin/sh, so it must be included in an essential package. But then we can't use alterternatives, which have to be organised from the maintainer scripts. Yep. This a more serious problem. I don't think its unsolvable, though; how does the current /bin/sh link get set up? I'd think bash postinst could change it to an alternative, but this leaves the problem of if update-alternatives requires a working /bin/sh The current link is part of the bash package. The preinst checks whether this either points to bash (or /bin/bash) and if not, that it is diverted using dpkg-divert. If neither of these are the case, the admin is warned of this and the link is reset to bash. Note that alternatives are handled from maintainer scripts and diversions from within dpkg itself (as well as via alternatives). I don't know the full rationale. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#161455: debian-policy: reference to ash outdated
On Thu, Sep 19, 2002 at 05:02:24PM -0600, Georg Lehner wrote: It is my opinion, that all sh-scripts involved in the standard system should be posix-sh compatible Correct; if you find one which isn't, please file a bug against the package. _and_ that the selection of the /bin/sh symlink should be realized by the alternative-mecanism instead of diverting. Technical problems here. Among other things, you'd have symlinks /bin/sh - /etc/alternatives/sh - /bin/something What happens if /etc is corrupted or not mounted or there are other problems? Then you wouldn't be able to boot linux with init=/bin/sh. Also, there is another major problem with using update-alternatives: we must *always* have a working /bin/sh, so it must be included in an essential package. But then we can't use alterternatives, which have to be organised from the maintainer scripts. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#161455: debian-policy: reference to ash outdated
On Thu, Sep 19, 2002 at 09:50:16AM -0600, Georg Lehner wrote: BTW: /bin/sh is a symlink to /bin/bash. Shouldn't it be an alternative so I can make ash or any other compliant, but smaller shall the default (and thus save memory and CPU requirements)?! /usr/share/doc/bash/README.Debian.gz Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: build-arch and autobuilders ?
On Wed, Sep 11, 2002 at 10:02:21PM +0200, Yann Dirson wrote: I couldn't find in policy 3.5.7.0 any requirement that would allow an autobuilder to know it should call debian/rules build-arch instead of debian/rules build, prior to call fakeroot debian/rules binary-arch. I thought (as outlined in a related bugreport, although my words in this report were a bit confused) that the policy should have made the binary-arch target mandatory, so that the atobuilders could know from the declared standard-version whether the target was expected or not. Currently it seems the autobuilders will have either to parse the rules file, or to attempt to use build-arch and parse the output if that failed - none of these alternatives seem reasonable to me. There was a long flame^Wdiscussion a while back about the possibility of doing something like the following: ret=$(set +e; debian/rules -q build-arch /dev/null 21; echo $?) if [ $ret -eq 2 ]; then debian/rules build else debian/rules build-arch fi This presumes that debian/rules understands the -q convention and gives the same exit codes as make does. This will be the case if debian/rules is a makefile, but if not [ducks and runs for cover!] Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: build-arch and autobuilders ?
On Thu, Sep 12, 2002 at 04:45:44PM +0200, Santiago Vila wrote: autobuilders might well just call debian/rules binary-arch and everything should work. What autobuilders actually do, I don't know. Note that binary* require root (or fakeroot) to build the .deb, whereas build* doesn't require root privileges. So the aim is to build without fakeroot and then call the binary* targets under fakeroot. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Interim update of policy planned for this weekend
On Wed, Aug 21, 2002 at 01:06:04PM -0500, Manoj Srivastava wrote: Hi folks, I shall be making an interim update of policy, including at least the /usr/doc transition changes, and invoke-rc.d changes. I'll also go through the BTS and include changes that have been accepted. Yeah, go Manoj!! Thanks, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#157131: Bug#113525: Bug#157131: [PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Tue, Aug 20, 2002 at 02:00:41PM +0900, Oohara Yuuma wrote: On 18 Aug 2002 20:18:43 -0400, Colin Walters [EMAIL PROTECTED] wrote: + Although binaries in the build tree should be compiled with + debugging information by default, How can I do it without wasting autobuilder's CPU time? See Ian Jackson's comments: this is, apparently, a spurious argument. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#157131: PROPOSAL] Suggest to minimize optimization when DEB_BUILD_OPTIONS contains debug
On Mon, Aug 19, 2002 at 09:19:02AM +0900, Oohara Yuuma wrote: On 18 Aug 2002 18:16:43 -0400, Colin Walters [EMAIL PROTECTED] wrote: + tagnoopt/tag + item + p + The presence of this string means that the package + should be complied with the minumum possible amount of + optimization. For C programs, this usually implies + adding tt-O0/tt to ttCFLAGS/tt. Some programs + might fail to build or run at this level of + optimization; it may be necessary to use tt-O1/tt. + /p + /item -O0 is the default of gcc. Why do I have to add it explicitly? I don't want a bug filed just because -O0 is missing. Good point. May in some cases be worth adding, though, if upstream makefiles add -O2 automatically. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Rewriting policy soonish if poss.
I've just had what I think is a really useful idea On Wed, Jul 31, 2002 at 02:13:36AM +1000, Anthony Towns wrote: __Debian Standards Document__ This makes a lot of sense as a separate, technical, document, as you say. But I think that (at least a part of) the sections which I asterisk below belong *also* in the policy/best packaging guidelines, for the ease of users: dpkg: * version format package format .deb is an ar of tars, etc * maintainer scripts are run when and under what circumstances * what control file fields mean source format * .dsc fields * .tar.gz, .diff.gz, .orig.tar.gz structure * debian/rules interface * contents/format of debian/control, debian/changelog etc dselect interfaces /var/lib/dpkg/status, available, dselect methods, etc internal dpkg interfaces /var/lib/dpkg/info, alternatives, statoverride debconf: * .templates format * .config arguments, etc interface for frontends * update-menus / menu file format (The debconf and menu stuff could simply be referred to wholesale, but the dpkg stuff is harder too.) But with the wonders of XML includes, we can simply have the common pieces in appropriate separate external files (or something cleverer, but that's a detail) and include them in both places. In this way, they will be both in the specs document (useful for specs!) and the guidelines (useful for package developers) and always be in sync - yeah! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Rewriting policy soonish if poss.
On Thu, Aug 01, 2002 at 12:08:03AM +1000, Anthony Towns wrote: On Wed, Jul 31, 2002 at 07:33:44AM -0600, Julian Gilbey wrote: On Wed, Jul 31, 2002 at 02:13:36AM +1000, Anthony Towns wrote: __Debian Standards Document__ dpkg: * version format * maintainer scripts are run when and under what circumstances Both of these are irrelevant to just about everybody, I'd've thought. Version number comparison is checked with 'dpkg --compare-versions', and the format is checked automatically by various tools. I've never found it necessary to look at the details of either except when I'm poking at apt or dpkg's internals, or when I've needed to do something really weird. I'm pretty sure maintainers frequently look at the specs of the version number format; not every package has something as nice as 2.3.2 as an upstream version number, and so knowing how version numbers work is important. But if this is the level of detail of our discussion, I think we're doing fine! * what control file fields mean Again, _what_ the fields mean (Essential: yes -- you can't uninstall a package easily, Depends: foo -- don't install this package unless foo's already installed) is a separate issue to when/why they should be used, and what effects their use has (Essential: yes -- installed on all Debian systems, so doesn't require a Depends unless it's new, in which case you need a versioned dependency, because of this rule, essential packages need to work unconfigured, etc). Developers need to know both when using them. But with the wonders of XML includes, we can simply have the common pieces in appropriate separate external files (or something cleverer, but that's a detail) and include them in both places. I think you're getting a bit over excited about the wonders of XML... 8-) In this way, they will be both in the specs document (useful for specs!) and the guidelines (useful for package developers) and always be in sync - yeah! Including them in the guidelines just gets in the way. That's what I was saying about trying to write up the BPP and finding the version comparison, etc section being uncomfortable. If package developers need them, they should look in the specs. Maybe. Maybe not. We'll think about this on a case-by-case basis. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Rewriting policy soonish if poss.
On Wed, Jul 31, 2002 at 02:13:36AM +1000, Anthony Towns wrote: On Sun, Jul 28, 2002 at 07:29:57AM -0600, Julian Gilbey wrote: To split the (often borderline) cases of specs versus guidelines seems to me to be somewhat misguided. Well, that's nice, but if our best reason is it seems to me, we're not going to get anywhere, because it seems to me to be quite the opposite. We could arm wrestle for it, I guess? For a more useful take, here, roughly, is what I'd think the tables of contents for the two documents might look like: I had completely misunderstood what you were thinking until you wrote this email, hence the confusion. I think what you are saying now makes a fair bit of sense, with some reservations: __Debian Standards Document__ dpkg: Most of the dpkg setup is so intricately connected with the packaging process, that separating out some of this seems somewhat weird. Although I guess that since this stuff is so clear and well-defined, it would be somewhat reasonable to simply cross-reference it. version format package format .deb is an ar of tars, etc maintainer scripts are run when and under what circumstances what control file fields mean source format .dsc fields .tar.gz, .diff.gz, .orig.tar.gz structure debian/rules interface contents/format of debian/control, debian/changelog etc dselect interfaces /var/lib/dpkg/status, available, dselect methods, etc internal dpkg interfaces /var/lib/dpkg/info, alternatives, statoverride debconf: .templates format .config arguments, etc interface for frontends update-menus / menu file format I guess I'm mostly with you on this one now. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Rewriting policy soonish if poss.
On Sun, Jul 28, 2002 at 01:31:26AM +1000, Anthony Towns wrote: On Thu, Jul 25, 2002 at 08:40:13AM -0600, Julian Gilbey wrote: I'd like to rewrite policy soonish. Into what, exactly? Last time this came up we had a nice flamewar about it, but didn't seem to resolve anything -- does it really make sense to do a rewrite while we as a project don't seem to have a clear idea of what policy's meant to be? Talking to Manoj the other day, I think it finally made sense to me what he was getting at, which leads me to think what we might be aiming at is to split policy into three separate docs: -- Release Critical Issues (a straight out list of problems that get a package pulled from testing, maintained by the RM) -- Debian Best Packaging Practices (guidelines on how to do packaging well, generally) -- The Debian Specifications Document (fairly formal specs on things like the version number format, format of .debs, layout of source packages, control file fields probably, update-rc.d spec, menu file format, and so on) Violations of the latter document can probably be checked completely automatically, and in many cases won't even make it into the archive. Many of the BPP guidelines will be able to be checked by lintian/linda too hopefully, at best only a few of them are worth RC bugs, though. I think this makes a lot of conceptual sense. However, I don't think that having three separate documents necessarily makes sense from a reader's or editor's point of view. I am certainly happy for you/the RM to maintain the list of RC bugs; that really is not within the purview of the -policy mailing list -- having said that, I would like to see a non-official version included in whatever form in the policy document itself, in ways we discussed in the past. Secondly, I absolutely see the value in clearly distinguishing between best packaging practices and the Debian policy/specs. However, to have to read two documents to find out how to package a library, which are likely to end up overlapping and probably contradicting each other, seems unhelpful, to say the least. To have clearly demarcated sections within the document (Specs/Policy and Best practice guidelines in the section on shared libs, for example) would seem to get the best of both worlds. Either way, we've been talking about this for ages, woody is now released, I haven't seen any evidence from anyone (myself included) that anyone's actually done something, and I really feel something needs to be done. So I will endeavour to squeeze some time out of my increasingly busy life to actually do this, unless someone beats me to it. (And I'll be delighted if that happens!) Any improvement on the current version of policy will be much appreciated by all concerned, I am sure. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rewriting policy soonish if poss.
On Sun, Jul 28, 2002 at 05:34:52PM +1000, Anthony Towns wrote: I think this makes a lot of conceptual sense. However, I don't think that having three separate documents necessarily makes sense from a reader's or editor's point of view. I'm inclined to disagree: I don't see there being any signficant overlap in the latter two documents at all, and I also suspect that stuff that goes in either one will be fundamentally different. To take version numbers as an example, I'd think the DSD would cover the format allowed by the tools (epochs, upstream, debian, valid characters, how they're compared, probably future directions (~)), whereas the BPP would tell you how to use that: try to avoid epochs, for alpha/pre versioning use something like 0.99-1.0pre1, how to base versions on dates, if you have to change the upstream tarball but upstream haven't released a new version tack something like +0 onto the end of the version, how to version an unofficial release (from CVS eg), and so on. Absolutely agreed that these are different. However, how does it serve our developers to have to look at two different documents when trying to find out how to come up with a version number? This issue has, as you point out, two clearly different aspects, which would be separated in any intelligent document, but there are other issues where the distinction is far less clear. (See, for example, all of the examples in the current policy.) I am *not* advocating munging everything into one confused paragraph, but clearly distinguishing examples and guidelines from standards/specs within one, easy-to-read, document. Secondly, I absolutely see the value in clearly distinguishing between best packaging practices and the Debian policy/specs. I'm not remotely using the word specs as a synonym for policy. They're not the same, and IMO, not even remotely similar. There are at least three different axes for policy issues: * violations result in unacceptable packages or violations are bad, but won't get you hung, drawn and quartered RCness; I think we're agreed that this is ultimately the RM's decision (with the possibility of appropriate discussion on particular cases). * automatically determinable or not automatically-determinable (alternatively rule can always be applied or rule needs to be applied with some judgement) MUST/SHOULD (in the RFC sense). * an interface used by many packages with Debian, or just a way of doing things that ends up with a good result Now here's the crunch: this is a description of best practice guildlines. But as you say, policy encompasses this. And I agree with you. IMO, policy encompasses *all* of those things. Trying to limit it to just the interfaces, or just the things that're always true or can be automatically tested, or just the things that're unacceptably horrible is unreasonably limiting, IMO. I'd consider it quite reasonable to have the BPP and DSD docs in debian-policy.deb, or to have two different .debs both maintained by this list, or similar. Our only disagreement seems to be over how the document/s is/are structured, not over the responsibility and content. However, to have to read two documents to find out how to package a library, which are likely to end up overlapping and probably contradicting each other, seems unhelpful, to say the least. debian-policy as it's stands overlaps with itself and contradicts itself. Agreed. Avoiding that isn't achieved by having one document instead of two, it's by maintaining it well. Avoiding that isn't NECESSARILY achieved Worse, there are in general many documents you need to read since a number of subsystem policies have been (unnecessarily, IMO) split from -policy: menu, debconf, perl, mime (within the same .deb at least), and python, library packaging, and so forth. Agreed. In any event, the BPP and DSD documents are fundamentally different. The former can have an attitude of these things work well in a number of cases, and might work well in yours too, and be a lot more dynamic and HOWTO oriented -- and IMO should have a section dedicated to the mini-policies of any groups that need them -- perl, python, games, libs, languages, whatever -- and it could easily refer you to the DSD for the details if necessary; while the DSD has to be fairly conservative (you shouldn't include new features, like say ~ in versions or DEB_BUILD_OPTIONS until everyone supports them -- dpkg, apt, the archive, and the buildds resepectively). To split the (often borderline) cases of specs versus guidelines seems to me to be somewhat misguided. Anyway, once I have something workable for a part of the new document, we can take a look at it and comment further. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Rewriting policy soonish if poss.
I'd like to rewrite policy soonish. I've been talking about it for ages, but life has been *so* busy I'm at an awesome summer camp right now as a mentor, and that's a 24/7 job, so it'll be a few weeks yet. Primary question right now: I know that Manoj has been talking about moving to the DocBook DTD for the next version of policy. What are people's experiences with it? How does it compare to the DebianDoc DTD for what we are likely to want to do? Could we easily create a rationale tag that is selectively (or even non-selectively) processed? Love to hear people's thoughts on the matter. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Objection to change made in debian policy
On Thu, Jun 06, 2002 at 01:16:40AM -0500, Adam Heath wrote: On Wed, 5 Jun 2002, Julian Gilbey wrote: On Tue, Jun 04, 2002 at 07:18:45PM -0500, Adam Heath wrote: On Mon, 3 Jun 2002, Chris Waters wrote: or, more simply: build binary-arch binary-indep binary clean: debian/myrules $@ Or, even simpler: %: debian/myrules $@ The latter might be problematic, if we require debian/rules -q build-arch to let us know whether a build-arch target exists, as will be required to make the best use of the build-depends-indep/build-depends split. Use MAKEFLAGS. How does that help if debian/myrules is a shoop/perl/python/... script? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Objection to change made in debian policy
On Tue, Jun 04, 2002 at 07:18:45PM -0500, Adam Heath wrote: On Mon, 3 Jun 2002, Chris Waters wrote: or, more simply: build binary-arch binary-indep binary clean: debian/myrules $@ Or, even simpler: %: debian/myrules $@ The latter might be problematic, if we require debian/rules -q build-arch to let us know whether a build-arch target exists, as will be required to make the best use of the build-depends-indep/build-depends split. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146023: suggested patch against policy, documenting libexec, or current custom on use of lib for binaries in lib* packages
On Sat, May 11, 2002 at 11:17:04AM +0900, Junichi Uekawa wrote: Steve Greenland [EMAIL PROTECTED] immo vero scripsit: How about simply: pIf your package includes run-time support programs that don't need to be invoked manually by the users, or named in a way that would cause conflicts if placed in tt$PATH/tt, but are nevertheless required for - the package to function, you should place them in a subdirectory of - file/usr/lib/file./p + the package to function, you should place them in a subdirectory named + file/usr/lib/pkgname/file./p Sounds better than my patch, and it seems to convey much of the information that I tried to convey. Although sometimes this is not correct, for example if multiple co-operating packages use the same /usr/lib/ subdirectory. And also, there's need to discuss /usr/share as well, as someone else already noted. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Fri, May 10, 2002 at 03:48:28AM +1000, Anthony Towns wrote: My suggestion for a policy rewrite it to move to the standard RFC uses of MUST and SHOULD, and indication RC-ness in an orthogonal way. In short, this isn't going to happen. There'll be a separate document, maintained by the release manager. It may or may not be included in debian-policy.deb. I'm inclined to think it'd be better if it were in that package, but we'll see. There is, I have just realised, a middle way, which satisfies your concerns and mine. There is an official list, maintained by you, and for convenience, the information could be included in policy, with the note that the official list can be found at URL. This would parallel the situation with the build-essential package, which provides a convenient way of knowing which packages are considered build-essential, even though the official definition is that given by policy. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Fri, May 10, 2002 at 11:25:33AM +1000, Anthony Towns wrote: For example, when talking about shared and static libraries, there may be exceptional cases where both the shared library and the development parts (headers and static library) live in the same package. Then one would say something like Source packages providing shared libraries SHOULD produce a binary package containing the shared library and another binary package containing the development files (headers and statically compiled library). The shared library MUST be compiled with the -fPIC option and the static library MUST NOT be compiled with this option. ... (Please don't correct me on details here -- I haven't checked them up and that's not the point.) Which is to say that if I demonstrate that your MUST or MUST NOT could happen to have exceptions, that you're not going to listen, and thus I've got no way of usefully demonstrating my point, which is that almost every MUST you might choose will have some sort of exception, and thus should be a SHOULD. In the above, for example, the xlibs-pic package provides static libraries that are compiled with -fPIC, making your MUST NOT inappropriate. So, assuming that this is correct behaviour, we have to use a SHOULD NOT at this point, not a MUST NOT. Why would we argue with that? So here, the SHOULD means that it must behave in this way unless there are exceptional circumstances, and the MUST means that there are no exceptions. I may be wrong in the details of this specific case, but this is the way I am thinking. I completely understand the distinction you're trying to make, I just think you'll find that there aren't many situations where MUST is appropriate, and that there aren't any where it's particularly useful. As crude examples: A package name MUST consist of [list permissible characters] and contain at least one letter. A package name MUST have at least two characters in it. Filenames MUST be unique within a distribution, unless they are handled using either Conflicts or dpkg-divert. (And there may well be other ways out, but I can't think of them offhand. You get the idea.) debian/rules MUST contain the following targets: debian/rules MAY contain the following additional targets with meanings specified below: debian/rules MAY contain other targets in addition to these. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Fri, May 10, 2002 at 03:48:28AM +1000, Anthony Towns wrote: On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote: On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: I'm concerned about this because when I tried passing over release-critical policy issues to the policy group, it didn't work. [..] Strawman (to quote lots of others). As a concept, it's very good, but as we discovered, the implementation was poor. As a concept it sucked, we just didn't realise it at the time. -policy isn't competent at judging which issues should be release critical. We didn't realise this before we tried, no we have tried and it's blatanly obvious. I'd suspect the reason it doesn't work is because there's no downside for -policy to making a rule a release-critical issue, compared to not doing it. You guys don't have to try to coerce people into fixing their RC bugs in a timely manner, nor throw out packages that don't have their RC bugs fixed, nor deal with the people who absolutely need the package. Whatever you say. Please note, however, the two distinct parts here: (1) Deciding what's RC. I agree with you that this is the job of the release manager. Rather you than me. (2) Recording the decisions. That can either go in a separate document as you describe, or in the body of policy in a clearly marked way as I have suggested. As it is clear that you are the only person who decides which issues are RC and which are not, -policy won't make those decisions but only record the decisions you have made. But at present all of this is hypothetical. Now back to real work. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Fri, May 03, 2002 at 09:34:58PM +1000, Anthony Towns wrote: On Thu, May 02, 2002 at 10:09:11AM +0100, Julian Gilbey wrote: Part I: The Debian Archive 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) Components is a much better word to use here. (And is the word used everywhere but -policy, just about) Fine. 2: The different distributions (stable, etc.) I.2 is probably more properly done in the developer's reference, since it doesn't impact how you go about constructing an ideal Debian package. It affects how you write the changelog entry. So maybe it should go in both. Priorities? Sections? Yes, of course. Part II: Packages and metadata [...] changelogs? copyright files? Of course. Perhaps something like: [...] ...would work out well? Maybe. Definately worth considering. Then each section could either have the structure: Policy dictate s Discussion, useful information, guidelines, examples or we could merge them, and have policy dictates all in the form MUST, SHOULD, MAY, MUST NOT, etc., as in the RFCs. I'm quite confident that trying to differentiate between requirements and guidelines like this will turn out to be completely unhelpful and a large waste of time, personally. Don't RFCs do this frequently? And I've never heard people making such a complaint about them. (As far as RC issues goes, this could be marked by (RC) after the MUST/SHOULD/whatever, with a catchall at the start of policy that the final decision on what is RC rests with the release manager.) As far as RC issues go, they'll be specified in an entirely separate document, not maintained by the policy group. Do you really expect bug submitters to consult yet another document, or is it just so that you can point people to it and say See, this is not considered an RC bug!? (I have no objection to there being another document per se or to the policy group not being in control of the list of RC issues.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: If the dpkg authors would like to hand off some of their design decisions to -policy on a generalised basis, I'm sure they'd say so. It seems a bit, well, wrong-headed for -policy to be trying to take control of dpkg though. Quite: IMHO discussion is about where the documentation should be found, not about the maintenance or control of dpkg! The dpkg developers do a great job, and I have much respect for them. since potentially large numbers of packages would be impacted by such changes. The dpkg maintainers are well aware of the likely impact of their changes, and are quite able to ask for advice when it's needed. I'm concerned about this because when I tried passing over release-critical policy issues to the policy group, it didn't work. Not only did everyone regularly and frequently lose track of what the point of must versus should was, but people just weren't very good at knowing when to choose which. Which is fine: we tried an experiment, it didn't work out how we'd hope, let's move on. But let's not just repeat the same mistake when there's no reason to do so. Strawman (to quote lots of others). As a concept, it's very good, but as we discovered, the implementation was poor. My suggestion for a policy rewrite it to move to the standard RFC uses of MUST and SHOULD, and indication RC-ness in an orthogonal way. I think this will make life easier for everyone, and I have no problems at all with the Release Manager dictating what he considers to be RC for this particular release. Further, considering that everyone seems to think that the -policy group have done pretty poorly at their actual job -- maintaining the policy document so that it's readable, consistent and useful -- it doesn't seem like a good idea to broaden its scope. Rewriting it into something comprehensible, making the already approved of changes, and merging all the subpolicies (at least debconf, perl, and python) is likely to be more than enough work for the forseeable future. Thanks. Appreciated. We need to rewrite policy, and have known this for absolutely ages, but when it absorbed the old packaging manual, it introduced the contradictions (oops). I vaguely recall that at that time, a freeze was effectively placed on substantially rewriting policy because of the upcoming freeze of woody. We are still in this freeze period, and both Manoj and I are itching to rewrite the current spaghetti which is called policy. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 03:20:45PM -0500, Manoj Srivastava wrote: Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian On Thu, May 02, 2002 at 02:30:34PM +0200, Wichert Akkerman wrote: Refer to a dpkg reference instead and document extra restrictions Julian Surely either everything necessary should be in the dpkg reference or Julian everything necessary should be in policy. q Umm, no. It does not make sense to restrict dpkg authors to a static, slow changing mechanism that is policy as the blueprint for their software development. The dpkg authors must be free to innovate, and document additional features, and evolving behaviour. Good point. On the other hand, all packages must not be left to the whimsy of the dpkg developers either; since potentially large numbers of packages would be impacted by such changes. Understood. Going to either extreme is suboptimal. Makes sense. What we need to do is specify a minimal set of interfaces that all packages are required to provide, and that the dpkg authors must maintain compatibility for. Agreed. Changes to this core functionality would require a transition plan to effect, but otherwise dpkg authors are free to make changes and extentions. Most extentions, when the become popular, would be candidates for inclution into the core interface, when the dpkg authors feel the interface has stabilized and would be unlikely to change. OK. But we must then be very careful about how the splitting of information works and how the two are kept compatible. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 12:03:38AM +1000, Anthony Towns wrote: and meet the most frequent complaint about the old policy + packaging manual: they contradict, and I have to look in two documents. Considering the packaging manual doesn't exist anymore, I don't see how anyone could make that complaint. People *used* to make that complaint. And if we now move to having a lean policy standards document and a developers reference and a best programming advice document and a dpkg documentation document, we'll have even more complaints in that direction. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 01:44:50AM -0500, Manoj Srivastava wrote: Anthony Policy at the moment provides a fairly thorough grounding in Anthony Debian's best practices. That's highly useful. Thorough is a matter of opinion. I think it is inconsistent, bumbling mess, occasionally wrong, and bloated, it occasionally contradicts itself, related issues are often scattered throughout the document, it does not have enough rationale. Its coverage of best practices is patchy, and what there is adds to the problem determining what is policy and what is the document merely being chatty. I totally agree with Manoj here. I think that before anyone sits down a rewrites the policy document (which we really need to do!), we should agree on a sensible structure that is likely to work. Doing too much detailed writing at this stage seems a little pointless. Here is a very brief attempt at a draft structure, which will certainly need improving, but gives an idea of what I mean: Part I: The Debian Archive 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) 2: The different distributions (stable, etc.) Part II: Packages and metadata 3: Package structure (source, binary, arch-dep/indep) 4: Control fields: source package fields 5: Control fields: binary package fields 6: Package dependencies: binary packages 7: Package dependencies: source packages Part III: Packaging scripts and files 8: Maintainer scripts 9: Other miscellany: debian/rules, changelog, files, substvars, etc. 10: Configuration files 11: Shared libraries Part IV: Other packaging issues 12: The operating system (cron, init.d, etc.) 13: Issues concerning files (permissions, links, scripts, etc.) 14: Documentation Part V: Debian subsystem issues 14: X Windows policy 15: Perl policy 16: Menu policy 17: Emacs policy ... Part VI: Programming guidelines and best practices [There may be something which fits here] Then each section could either have the structure: Policy dictates Discussion, useful information, guidelines, examples or we could merge them, and have policy dictates all in the form MUST, SHOULD, MAY, MUST NOT, etc., as in the RFCs. (As far as RC issues goes, this could be marked by (RC) after the MUST/SHOULD/whatever, with a catchall at the start of policy that the final decision on what is RC rests with the release manager.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Thu, May 02, 2002 at 02:30:34PM +0200, Wichert Akkerman wrote: Previously Julian Gilbey wrote: Part I: The Debian Archive 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) non-us is a different archive. I understand; this was just an imprecise abbreviation ;-) Sorry for any confusion. Part II: Packages and metadata Refer to a dpkg reference instead and document extra restrictions Surely either everything necessary should be in the dpkg reference or everything necessary should be in policy. I really don't want to see it split up into two separate documents, for that way lies madness again. I understand that dpkg can be used elsewhere than Debian, but it's de facto purpose is to serve as the Debian packaging system. So if the dpkg reference doesn't document everything that Debian needs in this respect, what is the best thing to do? To make people read two (possibly, even probably contradictory) documents? Or to have all of the relevant stuff in both documents? Ho hum. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and best packaging practices
On Tue, Apr 30, 2002 at 03:46:17PM -0500, Manoj Srivastava wrote: Hi, Apropos to that, Policy proper contains elements that ought not to be in there, but remain as vestigial documentation of dpkg (which is how policy started). Policy is going to be cleaned up and, and perhaps rewritten (probably in DocBook format) post woody (I like the layout of the sections in the FHS 2.2 document); and made into a more coherent, leaner version, as befits a standard document. Some of the examples need to be pruned from the policy proper; so a look into policy would be appreciated. My vision of policy is like that it is analogous to, say, the C standard, and not a DPKG for dummies or teach yourself packaging in 24 hours kind of document. It would be nice if the Debian Best Packaging Practices document plays a complementary role and picks up the slack. It would perhaps make policy more digestible. That sounds like a fabulous idea. What I would *really* like to see happen (and help with), post-woody, is something like the annotated C reference manual, which has the standard clearly identified, but lots of extra bits of rationale, examples, best practices and so on. In this way, we get the best of both worlds: we can create a clean standards-only document by some simple selective processing (ignore all extra sections when processing, or something like that), and meet the most frequent complaint about the old policy + packaging manual: they contradict, and I have to look in two documents. I've been thinking of having a merged policy/packaging manual for a while, but suddenly realised when I read your mail above that this might be the ideal way to do it to provide the best for everyone. Thoughts? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#138409: PROPOSAL] Add build environment data to package.changes files
On Thu, Mar 14, 2002 at 11:08:42PM -0800, Randolph Chung wrote: 2. Ideally one might want to recursively list all the dependents of build- dependencies too, but that is probably too expensive to compute. On my Pentium 166MHz, the following command took about 10s (real) to run, with devscripts (= 2.6.90) installed: polya:~ $ perl -I/usr/share/devscripts -MDevscripts::PackageDeps -e '$pkgs=new Devscripts::PackageDeps(/var/lib/dpkg/status); print join(\n,$pkgs-full_dependencies(build-essential)),\n' perl-modules cpp libstdc++2.10-glibc2.2 [...] binutils libstdc++2.10-dev make polya:~ $ It could be easily modified to give the required output. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#138409: PROPOSAL] Add build environment data to package.changes files
On Fri, Mar 15, 2002 at 07:14:44AM -0800, Randolph Chung wrote: 2. Ideally one might want to recursively list all the dependents of build- dependencies too, but that is probably too expensive to compute. On my Pentium 166MHz, the following command took about 10s (real) to run, with devscripts (= 2.6.90) installed: Thanks, that was good to know. one problem is that some packages have build-dependency chains that when resolved completely are very deep, and sometimes contains dependency cycles. One could argue that these are bugs, but they seem difficult to fix in some cases. As reference, here is an old build-dependency graph for bash: http://people.debian.org/~tausq/bash-build-deps.png (559k) The current bash only takes about 7-8 seconds. Dependency cycles are not a problem with my code: once a package is recorded as being a dependency, it's dependencies are added to a to-be-processed list, and then it is skipped if it is seen again. The to-be-processed list is ... well, processed. So my guess it that its time complexity is approximately linear in the size of the status file and the total number of dependencies. Replacing status with available so I can test some packages with more dependencies, I have not noticed a significant difference between bash (5 dependencies including itself) and gcompris (40 dependencies). If you can find a bigger one easily, I'll test that too! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Using deb packages to release proprietary software
On Fri, Mar 15, 2002 at 10:20:28AM -0300, Daniel Ruoso wrote: I want to publish the software in different stages (unstable, testing, frozen and stable, just like debian itself), because I will have machines testing each distribution. We no longer have a frozen. Finally, the question is... What's the better strategy to publish packages in the four dists? The easiest strategy: different directories for the different dists. Then people add the appropriate one to their sources.list files. The harder strategy: use pools and create appropriate Packages.gz files, as Debian now does. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#137172: removing Dan Quinlan's addr from policy
On Thu, Mar 14, 2002 at 12:02:00AM -0800, Chris Waters wrote: On Thu, Mar 07, 2002 at 12:51:04AM -0800, Chris Waters wrote: But if [Dan Quinlan] is no longer the contact, then I think that we do need to remove [his] name/email. Hi, this doesn't seem to be moving forward. There's only one second. We either need a second second (as it were), or we need some policy editor to decide that a change of this nature doesn't require seconds (a more reasonable approach IMO), and just to fix it. To recap: Dan Quinlan is no longer the FHS contact, and would like us to remove his email from policy. This is a simple administrative change, with no functional effect on Debian whatsoever, but it needs to be done. Freeze or no freeze. I'll do it if Anthony gives the go-ahead. Anthony: will typographical changes such as these be accepted into testing? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#137172: removing Dan Quinlan's addr from policy
On Thu, Mar 14, 2002 at 09:37:30PM +1000, Anthony Towns wrote: On Thu, Mar 14, 2002 at 10:17:18AM +, Julian Gilbey wrote: Anthony: will typographical changes such as these be accepted into testing? Yes. Just make sure it doesn't break stuff. OK. But it might now wait till next week -- I'm meant to be busy until Tuesday. If someone wants to do an NMU in the meantime, or even better, send me a patch to apply, I'll do it. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#137172: removing Dan Quinlan's addr from policy
On Thu, Mar 14, 2002 at 09:38:07AM -0600, Manoj Srivastava wrote: Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian I'll do it if Anthony gives the go-ahead. Oh, there are also a few accepted virtual package names that can also go in with no breakage ;-) And some typos. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#96597: changing policy requirements for debian native packages to _MUST_
On Sun, Mar 03, 2002 at 11:28:55PM -0500, Andres Salomon wrote: dh_installchangelogs (debhelper-3.4.11) currently bails if one attempts to install a non-debian changelog to /usr/share/doc/package/changelog.gz in a debian-native package. Joey Hess has mentioned that various tools expect the changelog.gz for debian-native packages to parsable as debian-style changelogs. Given Such as? Also, are you also installing a changelog.Debian.gz in the same package? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Policy being moved to docbook format
On Fri, Feb 01, 2002 at 04:39:25AM -0600, Manoj Srivastava wrote: I am considering breaking out chapters of the manual into their own entities/files, and perhaps handle the sub policies like that, so that the manual can be printed/put on the web as one extended entity, and still gain the benefits of having it as a separate file. Hi Manoj! I'm also thinking about radical changes to the layout of policy -- let's talk off-list about it in the first instance. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:19:25PM +0200, Jarno Elonen wrote: Hi, May I try to summarize the filesystem discussion on KDE list and suggest that it will continue in debian-policy? * Many people feel that KDE (and Gnome) is too large a whole to be stuffed in /usr/bin, /usr/share etc and would deserve a separate directory like X Interesting. * Some proposed using /opt/kde3. Arguments: Not as a Debian package. /opt is for third-party software. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#128868: debian-policy: Depends semantics unclear re circular depends
On Sat, Jan 12, 2002 at 07:08:21PM +1100, Peter Moulder wrote: From section 7.2 `Binary Dependencies' of debian-policy: #`Depends' # This declares an absolute dependency. A package will not be # configured unless all of the packages listed in its `Depends' # field have been correctly configured. Suppose that package A Depends on B, and package B Depends on A. My reading of the above policy excerpt is that is that circular dependencies are not allowed, since it would be impossible to configure either A or B without first configuring the other.[*1] Whereas, in fact, a number of dependency cycles do occur in Debian; a According to a recent post by Wichert to -devel, a cyclic dependency is OK, but all of the packages in the cycle have to be configured in the same dpkg invocation. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: Question about build dependencies.
On Mon, Dec 17, 2001 at 10:43:31PM +0100, Ola Lundqvist wrote: I think the policy have to be clearified on this matter. Maybe add a new paragraph that says something like (at the bottom of chapter 2.4.2. Dependencies other than binary packages can not be assumed, including network connection and other external hardware. Is that a good thing? Yes. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: Question about build dependencies.
On Mon, Dec 17, 2001 at 01:27:04PM -0800, Sean 'Shaleh' Perry wrote: Other checks can be build-dependencies of lynx, omt, ftp and other similar packages. Build dependencies of cvs is maybe a good check too. I've seen it before with other packages. lync could theoretically be used to dump an html file as plain text during the build. Silly, but possible. In fact, debian-policy does it ;-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: Should debian policy require to use debconf for postinst scripts?
On Thu, Dec 06, 2001 at 04:35:17PM +0100, Adrian Bunk wrote: It's some work for a maintainer to convert a package that simply uses things like cat EOM for interaction with the user to debconf - and if the maintainer is for any reason not willing to convert his package (he might even refuse a patch) the only way to force him to make this change is when policy says he has to do it. To pseudo-quote Anthony Towns on this one: policy is not a stick to hit lazy maintainers with. There is no way to force anyone, but patches are gratefully accepted by most maintainers. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Bug#121977: bad link to the original version in the MIME policy and the menu policy
Anthony, There are some URL errors in the current debian-policy package. Can we upload a patched version without changing any other content? Julian On Sun, Dec 02, 2001 at 12:07:58AM +0100, Josip Rodin wrote: On Sat, Dec 01, 2001 at 11:04:56PM +, Julian Gilbey wrote: Where exactly are you finding this incorrect URL? Like I said in the initial submission, and like the subject says, in the menu policy, and in the mime policy. Not the policy manual itself, but the two sub-policies. Ah, gotcha! Will correct. Will also do something with the URLs. But it'll have to wait till woody is released. But this isn't a change in the real content... 404s when referring to itself are really lame. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
On Sat, Dec 01, 2001 at 05:51:29PM -0500, Branden Robinson wrote: Summary: Per recent discussion on the debian-legal mailing list regarding DFSG section 3 and provisions of recent documentation-specific licenses that have been developed in recent years, that allow for non-modifiable portions of the work (such as the license text itself) and mandate the display of certain text on the outside surfaces of physical media, I am proposing a guideline for interpretation of the DFSG that clarifies the criteria that a license must meet to satisfy the DFSG. In principle, I approve of this idea. I haven't had time to think through the details. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Bug#121977: bad link to the original version in the MIME policy and the menu policy
On Sat, Dec 01, 2001 at 03:25:54PM +0100, Josip Rodin wrote: Package: debian-policy Hi, These two links: ftp://ftp.debian.org/debian/doc/package-developer/mime_policy.txt ftp://ftp.debian.org/debian/doc/package-developer/menu-policy.txt They are incorrect. Please fix them (the correction should be obvious :). TIA. Note to self: Correct URLs are: ftp://ftp.debian.org/debian/doc/package-developer/mime-policy.txt.gz ftp://ftp.debian.org/debian/doc/package-developer/menu-policy.txt.gz Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Bug#121977: bad link to the original version in the MIME policy and the menu policy
On Sat, Dec 01, 2001 at 10:06:38PM +0100, Josip Rodin wrote: On Sat, Dec 01, 2001 at 08:56:13PM +, Julian Gilbey wrote: Note to self: Correct URLs are: ftp://ftp.debian.org/debian/doc/package-developer/mime-policy.txt.gz ftp://ftp.debian.org/debian/doc/package-developer/menu-policy.txt.gz You should make that HTTP, too. Actually, which version of policy were you looking at? This was fixed in version 3.5.0.0, AFAICT. Closing this report. Uh, this is what I got from the the aforementioned FTP site :P I noticed this when I updated our scripts that copy that stuff to the web server. This doesn't make any sense to me. I just downloaded ftp://ftp.debian.org/debian/doc/package-developer/policy.txt.gz and it has the correct references in it. The version at http://www.debian.org/doc/debian-policy/ is correct as well. Where exactly are you finding this incorrect URL? (This is actually an FTP ref., not an HTTP ref. Maybe we should also put in HTTP refs.) No, I was suggesting that you replace FTP with HTTP. HTTP tends to have a smaller startup lag. In the text version, we have: It may also be found on the Debian FTP site ftp.debian.org as the file /debian/doc/package-developer/mime-policy.txt.gz, or in the equivalent location on your local mirror. Would be difficult to write that as http://ftp.debian.org/... ;-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Bug#121977: bad link to the original version in the MIME policy and the menu policy
On Sat, Dec 01, 2001 at 11:36:14PM +0100, Josip Rodin wrote: Where exactly are you finding this incorrect URL? Like I said in the initial submission, and like the subject says, in the menu policy, and in the mime policy. Not the policy manual itself, but the two sub-policies. Ah, gotcha! Will correct. Will also do something with the URLs. But it'll have to wait till woody is released. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: [vhost-base] Draft policy proposal
On Fri, Nov 30, 2001 at 09:29:32AM +1100, Daniel Stone wrote:
On Thu, Nov 29, 2001 at 01:55:29PM -0500, Joey Hess wrote:
Daniel Stone wrote:
[EMAIL PROTECTED]:~/policy% diff -urN fhs/fhs.txt{.orig,}
--- fhs/fhs.txt.origFri Nov 30 01:16:05 2001
+++ fhs/fhs.txt Fri Nov 30 01:19:02 2001
@@ -1736,6 +1736,7 @@
+-run Data relevant to running processes
+-spool Application spool data
+-tmp Temporary files preserved between system reboots
+ +-vhostsFiles relating to virtual hosts
Um, it is out of scope for the debian policy group to modify the FHS.
Cool. So should this be in policy?
Should what be?
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer
Queen Mary, Univ. of London see http://people.debian.org/~jdg/
http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/
Visit http://www.thehungersite.com/ to help feed the hungry
Also: http://www.helpthehungry.org/
Re: Non-C/C++/ObjC source files in /usr/include subdirectories
On Wed, Nov 21, 2001 at 11:18:20AM +0100, Florian Weimer wrote: Is it acceptable to put source files for non-C-related languages (such as Python, Perl, Ada, Java, and so on) in subdirectories under /usr/include? What are source files in this context? Note that /usr/include is generally not for source files, but for header files to be included during compilation. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
