Re: Are pure virtual Depends/Recommends entries bugs?
Hamish Moffatt [EMAIL PROTECTED] writes: Steinar mentioned problems with pure virtual build-deps. Those should work too. In the past bugs have been filed about those, but I think those are a problem because of bugs in the auto-build tools, rather than being an intrinsic problems with the deps. Hamish Builds are suposed to be deterministic and using a pure virtual build-deps causes a (somewhat) random package to be used on each build attempt and _can_ result in differen packages being used on different architecture or builds. For e.g. a libfoo-dev package this would result in different Depends on different archs or builds and so on. This is obviously not a good idea so virtual build-depends have been stronlgy discouraged. Also note that buildds will never install bar for Build-Depends: foo | bar for the same reason. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows [EMAIL PROTECTED] was heard to say: As I'm sure everyone knows, pure virtual entries in a Depends line are strongly deprecated, due to the fact that frontends have a tendency to pick a random provider of the package. What I'm not sure is if this is just ugly or actually considered a bug. In particular, I can't remember and would like to know: (a) Is a pure virtual entry with no prior alternative in a Depends line an actual bug? i.e., do we have a consensus on this? (b) If the answer to (a) is yes, is a pure virtual *Recommendation* a bug? Rationale: Recommendations are intended to be installed by default, so their fields should be just as friendly to automatic tools as Depends is. So can I take it that the answer to my question is there is no such policy? Daniel signature.asc Description: Digital signature
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: (a) Is a pure virtual entry with no prior alternative in a Depends line an actual bug? i.e., do we have a consensus on this? This will prevent the package from autobuilding, which is a bug. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
* Steinar H. Gunderson [Sat, 05 Nov 2005 19:46:21 +0100]: On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: (a) Is a pure virtual entry with no prior alternative in a Depends line an actual bug? i.e., do we have a consensus on this? This will prevent the package from autobuilding, which is a bug. That would be for Build-Depends, though it could cause failures for rev-build-depending packages. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Matthew Kimball - I don't want to fall in love You've come to the right place. At debian-devel we are always willing to argue over the meanings of words. -- seen on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are pure virtual Depends/Recommends entries bugs?
On Mon, Oct 31, 2005 at 10:55:18PM -0500, Daniel Burrows wrote: As I'm sure everyone knows, pure virtual entries in a Depends line are strongly deprecated, due to the fact that frontends have a tendency to pick a random provider of the package. What I'm not sure is if this is just ugly or actually considered a bug. In particular, I can't remember and would like to know: (a) Is a pure virtual entry with no prior alternative in a Depends line an actual bug? i.e., do we have a consensus on this? (b) If the answer to (a) is yes, is a pure virtual *Recommendation* a bug? Rationale: Recommendations are intended to be installed by default, so their fields should be just as friendly to automatic tools as Depends is. I don't think a pure virtual dependency (or recommendation) should be a bug. If there is really no reason to choose one provider or another, why choose one artificially? I expect a tool like aptitude might pick the candidate with highest priority, or else one at random (or the first one in some sort order). A package maintainer could pick one this way too, but then it's one more thing to maintain. Steinar mentioned problems with pure virtual build-deps. Those should work too. In the past bugs have been filed about those, but I think those are a problem because of bugs in the auto-build tools, rather than being an intrinsic problems with the deps. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
