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 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. * 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). 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... 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. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp271nWJsXk6.pgp Description: PGP signature
Re: Rewriting policy soonish if poss.
On Thu, 1 Aug 2002 00:08:03 +1000, Anthony Towns aj@azure.humbug.org.au wrote: 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. You say I should read the source of dpkg when I need to do something really weird about version number (cope with -pre and -beta, rebuild with dbs and so on)? Digits, dots and hyphens do not always work. -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 her occasionally near suicidal sense of loyal self-sacrifice --- Luke Seubert, about what Rei Ayanami and Debian developers have in common
Re: Rewriting policy soonish if poss.
On Thu, Aug 01, 2002 at 12:06:55AM +0900, Oohara Yuuma wrote: On Thu, 1 Aug 2002 00:08:03 +1000, Anthony Towns aj@azure.humbug.org.au wrote: 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. You say I should read the source of dpkg when I need to do something really weird about version number (cope with -pre and -beta, rebuild with dbs and so on)? Digits, dots and hyphens do not always work. No, I'm saying you should read the Specs Document. (Advice on coping with -pre and -beta and such should be in the Best Practices doc anyway though -- generalising from how the version comparison stuff works to a good way of handling pre-versions is non-trivial. Well, without ~, it is, anyway.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
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 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: __Best Packaging Practices__ Making a package Locating your package (server, component, priority, tasks, sections) Versioning your package Architecture considerations When to use Depends/Pre-Depends/Recommends/Suggests/Provides Effects of Essential: yes? What to put in your Description Making a source package should you do things... by hand? with debhelper? with debstd? with dbs? with cvs-buildpackage? how you should write your changelog copyright file what gcc options to use, environment variables to use supporting DEB_BUILD_OPTIONS Other general stuff file locations /usr/share/doc symlinks users and groups file permissions dpkg-statoverride, and when packages should use it preinst, postinst, prerm, postrm what tools are available when to prompt configuration conffiles versus postinst when and how to change from to the other what happens when your conffile _has_ to change sharing configuration files amongst multiple packages that aren't installed together that are installed together automatically handling files in /etc automatically updating config files /etc/auto and symlinks, etc init scripts (which runlevels, messages, how to write them) cron jobs menus environment variables don't expect them $EDITOR || /bin/editor $PAGER || /bin/pager alternatives versus Provides/Conflicts MIME stuff /dev/* user configuration files log files ptys, wtmp, utmp, lastlog i18n/l10n references for gettext, man pages, debconf keyboard handling misc security info /tmp/races and how to avoid them renaming, merging and spliting packages don't do it! dummy packages replaces conflicts/provides Special cases for when you're packaging... ...scripts put a #! in them /bin/sh for POSIX scripts /bin/bash for bash scripts, but use /bin/sh if possible t/csh scripts need deps on c-shell perl scripts can only use stuff in perl-base python scripts need deps on python .../bin/sh interpretors diversions only (and how to manage it) what you have to comply with ...internet servers when to use inetd / standalone, how to offer the choice how to use inetd how to get /etc/services updated using TCP-wrappers ...documentation ...C libraries ...emacs stuff ...fonts ...games ...MTAs, MDAs and MUAs ...perl stuff ...python stuff ...webservers ...web services ...X servers ...X clients ...X terminal emulators ...X window managers There's probably a better way of structuring it. __Debian Standards Document__ 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 There're probably other interfaces that're complicated enough to deserve formal documentation. SELinux might be one, eventually. I'm not really sure, perhaps Manoj'll comment. Basically, to my mind, BPP should be focussing on the what and the why, and basically always refer the details of /how/ to other documents, either some program/package's manpages or the Debian Specs Document. The Or Else should be kept minimal, and left entirely to other groups (the RM, the tech ctte, the archive scripts, eg), IMO. This is the policy shouldn't be a stick philosophy. So why should you care about either document? Abusing dpkg's
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 Tue, Jul 30, 2002 at 11:44:38AM -0600, Julian Gilbey wrote: __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. Well, the version format ([epoch]:[upstream]-[debian]), and particularly how version numbers are compared can be split out reasonably. The intricate details of how a .deb is made up, likewise. The archive's expectations of what a source package is (and what a .changes file is, for that matter), don't really affect the details of packaging much, either. The debian/rules interface might or mightn't be worth specing outside of policy, I don't know if anything but dpkg-buildpackage actually needs to care that much. I guess I'm mostly with you on this one now. Cool. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgp8bt5kNOwLl.pgp Description: PGP signature
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
Re: Rewriting policy soonish if poss.
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. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpouqAHJuxV4.pgp Description: PGP signature
Re: Rewriting policy soonish if poss.
At (time_t)1027611024 Sebastian Rittau wrote: I would rather recommend using the existing Note tag with a Role=rationale attribute. This is a good idea. Extending DocBook with new tags is trivial, but is best done only when DocBook clearly fails to provide a needed construct. The stylesheets are generally quite flexible, and can be extended to handle the role. It may be tempting, if the rationales are intended to be footnotes, to add a role attribute to the footnote tag instead, but that would be a needless confusion of content with presentation. Let the stylesheet dictate how rationales are presented. Love to hear people's thoughts on the matter. I think converting the policy to DocBook is the right way to go. Seconded. We at Progeny use DocBook/XML extensively, and it has served us very well. One advantage of DocBook over DebianDoc that we haven't leveraged yet is indexing, which is something I've sorely missed when looking for information in Policy and the DDR. -- John R. Daily emailmailboxjohn/mailboxdomaingeekhavoc.com/domain/email -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: Rewriting policy soonish if poss.
Previously Julian Gilbey wrote: 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? I use DocBook for all documents and manpages now and it works great. 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? I don't see why not. You can create your own stylesheet and add a rational thing in there, or use something like XSLT to add customized tags in your document and convert them into proper docbook when needed. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rewriting policy soonish if poss.
On Thu, Jul 25, 2002 at 08:40:13AM -0600, Julian Gilbey wrote: 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? I would rather recommend using the existing Note tag with a Role=rationale attribute. Love to hear people's thoughts on the matter. I think converting the policy to DocBook is the right way to go. - Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
