Heya, net-p2p/bittorrent-4.4.0 has a blocker which is virtual/bittorrent, but it also provides it. Guess that is bad :( Regards, Alexander
Nope, there's nothing wrong with that. Same is done for packages providing virtual/mta, e.g.
Jakub, you're wrong here. IMHO this is a bug and it was me who told eroyf to file a bug.
Assigning to net-p2p@g.o, CC'ing qa@gentoo.org.
No, it's not a bug. Again, see all the ebuilds that provide virtual/mta.
@kugelfang, key thing is "imho"; majority of the tree disagrees with you on this one, and the reasoning for support blocking the virtual a pkg provides (as annnoying as it may be to implement in a resolver) is to enable blocking a common point, rather then having to try to block every potential provider of the virtual. It's long term correct behaviour; stating it's not doesn't invalidate years of reliance on this feature; non bug.
one exemption here is if the comment is specifically that bittorrent is blocking virtual (blocking all others), and isn't required; that's seperate from "old style providers can't block the virtuals they provide".
@Ferringb: You are no dev anymore. You _should_ know how to operate in here. Please don't remove foreign aliases anymore, especially as the CC'ed party could not respond yet, or I will take appropriate means to keep you from doing so. @Portage-devs,qa,net-p2p: There are ways to circumvent blocking the virtual, specifically to move it to a new-style virtual. What I would like to elaborate: Is it worth to do this move to circumvent a nuisance like "Package indirectly blocks itself".
(In reply to comment #7) > @Ferringb: You are no dev anymore. You _should_ know how to operate in here. > Please don't remove foreign aliases anymore, especially as the CC'ed party > could not respond yet, or I will take appropriate means to keep you from doing > so. Portage devs are the folks who control depset behaviour, not QA, hence the reassign. Either way will let them comment.
There's no need to circumvent anything here. New style virtual won't solve the issue we are talking about here. To re-iterate: You have X packages providing the same functionality and same binaries, so you still need the blocker to be valid, new-style virtual will only complicate the situation needlessly. It will be plain redundant and you'll have to stick individual blockers into every single ebuild "providing" the virtual, since you can't block the new-style virtual as a whole anymore. Where's the advantage in this I fail to see. I also don't see what's the QA issue here.
Jakub: You're right, new-style virtual can not fix it. Still, an ebuild blocking the virtual it provides, blocks itself (indirectly). What is the reason not to block all other providers?
test
(In reply to comment #10) > Jakub: You're right, new-style virtual can not fix it. Still, an ebuild > blocking the virtual it provides, blocks itself (indirectly). new style can 'fix it'; basically need disjunctive form of an XOR for it however (which to quote jstubbs, is "horrid horrid horrid" ;) > What is the reason not to block all other providers? !virtual/bittorrent in a pkg that provides virtual/bittorrent *is* blocking all other providers; assume miscommunication here, or you're missing how it's interpreted...
(In reply to comment #10) > What is the reason not to block all other providers? Assume all n packages that provide the virtual block the virtual. Every time you add a new package that provides the same virtual, you have to edit 1 ebuild (the new one). Assume all n packages that provide the virtual block the other packages providing the virtual. Every time you add a new package that provides the same virtual, you have to edit n+1 packages' ebuilds. I leave it up to you which one is better in regard to maintainability ;)
I'll keep this short... "New style" virtuals don't cover the common case of a package blocking against the virtual that depends on itself. A current workaround is to use the "old style" virtuals' PROVIDE metadata in the related packages. "New style" virtuals should RDEPEND on the virtual package to indicate that they "provide" the virtual. This can be solved with two key additions. XOR deps in addition to the existing OR and (implicit) AND deps; and (minimally) enforcing blockers from installed packages. Theoretically, only the latter is required. With the latter, a "one package only" virtual would look something like: RDEPEND="|| ( ( a !b !c ) ( !a b !c ) ( !a !b c ) )" With XOR deps, this would be reduced to: RDEPEND="^^ ( a b c )" That about covers it.. There may be other more elegant solutions, but this needs to be discussed on -dev@ anyway. Will do so sometime this week when I'm not working. As for bittorrent, it already has a PROVIDE of virtual/bittorrent so it is adhering to the "old style" virtuals "specification" as implemented in all portage versions supporting virtuals.
Thank you Jason, i'm looking forward to your mail.
After discussing this with others, I realized that adding XOR support will likely require an EAPI change. That's going to result in a whole heap of discussion/arguing that I really don't want to bother with. I'm happy to implement what's left to support the complete dropping of old-style virtuals. Opening it for discussion on -dev and getting it approved? I'll cowardly leave that to somebody else.
