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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
