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]
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]
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: 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
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: [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 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]
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]
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
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
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
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: 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
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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 Sat, Jul 27, 2002 at 10:55:14PM -0600, Julian Gilbey wrote:
> 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?
> > [...] split policy into three separate docs:
> > -- Release Critical Issues
> > -- Debian Best Packaging Practices
> > -- The Debian Specifications Document
Other possible names for the latter document are "The Debian Standards",
or "Debian Standard Interfaces" or something similar.
> 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.
> 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
* automatically determinable or not automatically-determinable
(alternatively "rule can always be applied or rule needs to be
applied with some judgement")
* an interface used by many packages with Debian, or just a way of
doing things that ends up with a good result
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.
> 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. Avoiding that isn't achieved by having one document instead
of two, it's by maintaining it well. 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.
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).
As another example, the ".deb" section of the DSD document would probably
describe "Essential: yes" as indication to package tools not to allow the
user to remove the package easily, while the BPP document would cover
the fact that essential and required packages are expected to continue
working when unpacked-but-not-configured, and thus should generally use
pre-depends: instead of depends: and should not rely on their postinst
being run in order to work correctly.
It's not clear to me where you'd want to draw the line between putting
some specs in, say, dpkg's documentation versus putting it in a broader
document like the DSD. Things like the arguments to dpkg-buildpackage
should probably stay in dpkg's manpages, even though other tools use them,
but it's probably useful to keep things like the version number format,
and maybe the source package format, or the .deb package format in a
DSD like document.
> To have clearly demarcated
> sections within the document ("Specs/Policy" and "Best practice
> guidelines" in th
