"only declare Provides when"

[Bruce Sass <bmsass@shaw.ca>]

On Mon August 14 2006 00:03, Steve Langasek wrote:
> ... my premise
> that pure python modules should only declare Provides when something
> exists in the archive which actually *needs* them...

What of stuff which will never be in the archive?

["ask for it" is an obvious answer, so...]
Any thoughts on handling developers when Debian's Maintainer disagrees 
as to whether their package *needs* to declare a Provides or is slow 
providing it?

I'm thinking of scenarios like:

- packaging stuff for Debian

  Package can't be tested until the Provides appears and there may be
  more than one way to do the new packaging, so: build a local package
  to Provide, wait and NMU, or bug report and wait.

- in-house/3rd-party packages

  In addition to needing a Provides Debian doesn't there may be need
  to package in a non-Debian manner (leading to the second question),
  so: local packages, or file bug report

- non-free non-redistributable

  Should be no different than in-house/3rd, but some Maintainers want
  nothing to do with non-free and may balk or delay at Providing for
  `non-free crap' that's not even free enough for non-free. [only
  brought up as a potential bad press/flamewar alert, should not be
  taken as crying 'cause non-free has a harder time of it :-]


I have a feeling that Providing local X.Y-foo's for all installed X.Y's 
could work without hurt under that premise. I'm not sure how to 
communicate X.Y+foo="X.Y-foo" to other packages, or if it is necessary 
to do that (worst case: install of foo fails and user see that X.Y is 
needed?)

Local virtual Provides could be (uhm) interesting.


Is there any way around these problems which doesn't require on-the-fly 
package creation or dpkg DB editing, or maybe they are not really 
problems?


- Bruce