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: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sat, Jul 27, 2002 at 09:28:56PM -0500, Branden Robinson wrote: On Sat, Jul 27, 2002 at 09:20:03PM +0100, Mark Brown wrote: It seems pointless given that you can't actually depend on the package and expect it to do anything in particular - the package seems to serve no purpose. I mean, as far as I can tell a package providing access to These appear to be equally valid arguments against all other virtual packages in Debian. I wouldn't say so. For example, a C compiler ought to provide /usr/bin/cc in some form or another, a mail transport agent ought to provide a /usr/sbin/sendmail implementation and a web server ought to serve things out of /var/www by default. Other virtual packages appear to be more about ensuring that only one package tries to use a given resource at one time. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- 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
HUHU kennst du mich noch?
Hallo, lange her dass wir uns getroffen haben...aber ich kenne dich noch ! Hab jetzt endlich meine Homepage erneuert. http://sandrachat.bl.am hoffe man sieht sich mal wieder im Chat. Sandra
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote: I wouldn't say so. For example, a C compiler ought to provide /usr/bin/cc in some form or another, You're talking about an alternative for /usr/bin/cc. A thing that compiles C source code into object files is a C compiler regardless of where its binary lives or what it's called. a mail transport agent ought to provide a /usr/sbin/sendmail implementation Only if policy says so. In and of itself this isn't a requirement mandated by the fact that Provides: mail-transport-agent is in a package's control data. and a web server ought to serve things out of /var/www by default. Purely an FHS issue. A web server is a thing that speaks HTTP over a network interface (which may be virtualized). By the way, the virtual package name for a web server is httpd. Other virtual packages appear to be more about ensuring that only one package tries to use a given resource at one time. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I don't think that is possible in the former case due to /usr/sbin/sendmail, but that's something we decided to do and not an inherent restriction imposed by the MTAs themselves. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. However, I give up. Unless the maintainers of the various and sundry DHCP client packages in Debian decide to cooperate there's no way that #154142 can be solved in a way that makes both the submitter and the maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, when a DCHP client package dies, etherconf will refer to a nonexistent one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. I expect you to be calling for the removal of a great many virtual packages listed in /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, because they define an insufficiently strict interface. pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the pdf-viewer input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that only one pdf-viewer is installed at a time; there are precious resources that are monopolized by such tools. We need to be enhancing the user experience in Debian by doing away with these meaningless virtual packages! -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen pgpByEzsDh7yI.pgp Description: PGP signature
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote: Branden These appear to be equally valid arguments against all Branden other virtual packages in Debian. To mee this is simply an argument that the description entry in the virtual packages list should be carefully written in this (and really all other) case. Perhaps something like DHCP clients compatible with ifup/ifdown This discussion appears to be irrelevant. None of the DHCP client maintainers has said, yes, good idea, I'll do this, therefore it's dead in the water. I doubt that providing a description as you suggest will do anything to overcome Mark Brown's opposition to the idea. -- G. Branden Robinson|A committee is a life form with six Debian GNU/Linux |or more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | pgphR0tHl11Fi.pgp Description: PGP signature
make it official
retitle 154142 [PROPOSED] dhcp-client virtual package
reassign 154142 debian-policy
severity 154142 wishlist
thanks
--- virtual-package-names-list.txt~ 2002-07-28 13:11:31.0 -0500
+++ virtual-package-names-list.txt 2002-07-28 13:13:37.0 -0500
@@ -63,6 +63,7 @@
awk Anything providing suitable /usr/bin/{awk,nawk} (*)
c-compiler Anything providing a C compiler
c-shell Anything providing a suitable /bin/csh (*)
+dhcp-client Any package providing a DHCP client
dotfile-module Anything that provides a module for the
Dotfile Generator
dict-client Any package providing clients for the Dictionary Server
I am seeking seconds for this proposal.
--
G. Branden Robinson|
Debian GNU/Linux | If ignorance is bliss,
[EMAIL PROTECTED] | is omniscience hell?
http://people.debian.org/~branden/ |
pgpcEQLeory77.pgp
Description: PGP signature
Processed: make it official
Processing commands for [EMAIL PROTECTED]: retitle 154142 [PROPOSED] dhcp-client virtual package Bug#154142: etherconf only depends on dhcp-client Changed Bug title. reassign 154142 debian-policy Bug#154142: [PROPOSED] dhcp-client virtual package Bug reassigned from package `etherconf' to `debian-policy'. severity 154142 wishlist Bug#154142: [PROPOSED] dhcp-client virtual package Severity set to `wishlist'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make it official
On Jul 28, Branden Robinson [EMAIL PROTECTED] wrote: I am seeking seconds for this proposal. Seconded. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, Jul 28, 2002 at 01:00:55PM -0500, Branden Robinson wrote: On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote: all other) case. Perhaps something like DHCP clients compatible with ifup/ifdown dead in the water. I doubt that providing a description as you suggest will do anything to overcome Mark Brown's opposition to the idea. Your doubts are unfounded - that description works for me. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make it official
On Sun, Jul 28, 2002 at 01:14:57PM -0500, Branden Robinson wrote: I am seeking seconds for this proposal. seconded. -- michael d. ivey[McQ] : Every artist was first an amateur. [EMAIL PROTECTED] : -- Ralph Waldo Emerson http://gweezlebur.com/~ivey/ : encrypted email preferred : pgpxZCCNXeL5J.pgp Description: PGP signature
Re: make it official
On Sun, Jul 28, 2002 at 01:14:57PM -0500, Branden Robinson wrote:
--- virtual-package-names-list.txt~ 2002-07-28 13:11:31.0 -0500
+++ virtual-package-names-list.txt 2002-07-28 13:13:37.0 -0500
@@ -63,6 +63,7 @@
awk Anything providing suitable /usr/bin/{awk,nawk} (*)
c-compiler Anything providing a C compiler
c-shell Anything providing a suitable /bin/csh (*)
+dhcp-client Any package providing a DHCP client
dotfile-module Anything that provides a module for the
Dotfile Generator
dict-client Any package providing clients for the Dictionary
Server
The only possible issue that I can see is that the introduction of this
virtual package would leave no way to depend specifically on the ISC DHCP
client 2.x, which is currently named dhcp-client.
There are several packages in sid which reference dhcp-client, but after
examining them, none of them appear to need this specific client, and would
be better off depending on a dhcp-client virtual package. So this seems to
be a non-issue in Debian at this point, unless someone who knows better
speaks up.
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make it official
Previously Matt Zimmerman wrote: The only possible issue that I can see is that the introduction of this virtual package would leave no way to depend specifically on the ISC DHCP client 2.x, which is currently named dhcp-client. You could take advantage of the fact that dpkg doesn't support versioned virtual packges at the moment and use a versioned dependency to make sure you get the real dhcp-client. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 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: [epg@progeny.com: Bug#154142: dhcp-client conflicts]
On Sun, Jul 28, 2002 at 12:57:19PM -0500, Branden Robinson wrote: On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote: a mail transport agent ought to provide a /usr/sbin/sendmail implementation Only if policy says so. In and of itself this isn't a requirement mandated by the fact that Provides: mail-transport-agent is in a package's control data. Yet irrespective of policy any package not providing /usr/sbin/sendmail and claiming to be a mail-transport-agent is going to break a fair chunk of the packages which declare a dependency on that virtual package since they declare the dependency because they need to use that interface. This is one of the reasons why we specify what a package must do to be considered a mail-transport-agent. There's no fundamental reason you couldn't have multiple MTAs listening on different ports, or different web servers on different ports. I I agree. I think it would be a good thing if this were well supported by the packages providing servers. I suggest folks simply read Policy 7.4 and understand virtual packages for what they are: no less, and *no more*. I've read it before, I've just re-read it and I still don't see why you'd want to be having packages satisfy dpkg dependencies when they don't satisfy the actual dependencies. maintainer happy. Every time a new DHCP client is packaged for Debian a bug will have to be filed against etherconf wailing that some person's favorite DHCP client is unfairly discriminated against. (And worse, You still have this problem every time a package implements this virtual package with a new interface. one.) The package's Depends: line will get longer and longer for no particularly good reason, except that some folks have these mystical notions about what a virtual package is good for. It's more mystical notions about what the dependency information we provide for packages is good for. pdf-viewer for instance. What possible good is that? It doesn't tell you what it's called or what options to give it! It doesn't even say if you feed the pdf-viewer input on standard in or if it takes the input as argument on its command line! And Lord knows we have to be sure that If you were to really push for something I'd suggest that the interface a pdf-viewer should provide is that we normally use for handling MIME but that's not really the point and doesn't apply to a lot of the other virtual packages. These are like news-reader where the idea appears to be that a user will use the package for themselves (This package will be pretty useless unless you can view PDFs - I suggest you have a PDF viewer installed). I'm rather ambivalent about the usefulness of this given the difficulty in implementing user interfaces for suggests and recommends but that's another matter. dhcp-client really doesn't seem like it's going to be used like that - the context that sparked its request certainly isn't one where that's the case. It's not about asking for publication ready standards documents for virtual packages. Adding supported by ifupdown as was suggested would do everything that's being asked for if it's how dhcp-client is supposed to be used. Having said all that, given the enthusiasm with which your formal proposal has been greeted I guess I'm just misunderstanding why we have dependencies. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#154660: FTBFS: missing build-dependencies
Package: debian-policy Version: 3.5.6.1 Severity: serious The debian-policy package is missing a build-dependency on docbook-utils; the package does not build from source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
