portage/pkgcore: ~cat/foo-${PVR} is treated like ~cat/foo-${PV}, i.e., the -r* part is ignored. paludis/PMS: ~cat/foo-${PVR} is treated kinda like =cat/foo-${PV}-r* !<cat/foo-${PV} (yeah I know the first atom is invalid :P) Also the wording is pretty awkward in PMS. Well anyway, I don't think that either behaviour makes sense, and would suggest that ~cat/foo-${PVR} should be invalid atom. :) Given the current portage behaviour, it cannot be safely used with the meaning described in PMS anyway, because it won't work that way, and it's not used anywhere in gentoo-x86 in this way. FWIW, this is what devmanual says and this matches how's ~ been used for ages, i.e., with ${PV} only and never with ${PVR}. ~app-misc/foo-1.23 Version 1.23 (or any 1.23-r*) is required.
The wording in PMS for this is deliberate... Portage's behaviour when -r is present is silly and illogical; the described behaviour is sensible and useful. This is one of the differences where Portage should be fixed to match the spec.
The point is - it can't be (and isn't) used as described in PMS with EAPI=0 - because it simply doesn't work that way. PMS clearly describes this as EAPI=0 behaviour - it's not, never worked this way.
PMS describes Portage's behaviour, except where Portage's behaviour is clearly nonsensical or wrong. Ignoring part of the spec is clearly nonsensical.
Nice circular reasoning.
Uh, there's no circular reasoning there...
"spec descripes implementation behavior, except where it's nonsensical" "implementation behavior is nonsensical because it ignores the spec"
No no. Other meaning of spec. It's nonsensical because it ignores part of the cat/pkg-pv-r -- specifically, the -r part.
Assuming for the moment that the spec is adhered to, who is going to fix all the non-conforming dependency strings? It seems a tall order to change this in EAPI-0 since it forces tree-wide changes, IMHO. Would it not be better served in a future EAPI?
So far as I can see, there's exactly one package in the tree where this matters, and it looks like it's after the behaviour described in PMS anyway... #include <paludis/paludis.hh> #include <iostream> using namespace paludis; namespace { struct FindB0rkedVisitor : ConstVisitor<DependencySpecTree>, ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, AllDepSpec>, ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, AnyDepSpec>, ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, UseDepSpec> { std::string bad; void visit_leaf(const PackageDepSpec & s) { if (s.version_requirements_ptr()) for (VersionRequirements::ConstIterator v(s.version_requirements_ptr()->begin()), v_end(s.version_requirements_ptr()->end()) ; v != v_end ; ++v) if (v->version_operator == vo_tilde) if (v->version_spec.revision_only() != "r0") bad.append(stringify(s) + " "); } void visit_leaf(const BlockDepSpec & s) { visit_leaf(*s.blocked_spec()); } void visit_leaf(const NamedSetDepSpec &) { } void visit_leaf(const DependencyLabelsDepSpec &) { } using ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, AllDepSpec>::visit_sequence; using ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, AnyDepSpec>::visit_sequence; using ConstVisitor<DependencySpecTree>::VisitConstSequence<FindB0rkedVisitor, UseDepSpec>::visit_sequence; }; } int main(int, char *[]) { tr1::shared_ptr<const Environment> env(EnvironmentMaker::get_instance()->make_from_spec("")); tr1::shared_ptr<const PackageIDSequence> ids( env->package_database()->query(query::Repository(RepositoryName("gentoo")), qo_whatever)); for (IndirectIterator<PackageIDSequence::ConstIterator> i(ids->begin()), i_end(ids->end()) ; i != i_end ; ++i) { FindB0rkedVisitor v; if (i->build_dependencies_key()) i->build_dependencies_key()->value()->accept(v); if (i->run_dependencies_key()) i->run_dependencies_key()->value()->accept(v); if (i->post_dependencies_key()) i->post_dependencies_key()->value()->accept(v); if (! v.bad.empty()) std::cout << *i << ": " << v.bad << std::endl; } } Gives: app-office/gnucash-2.0.5:0::gentoo: ~dev-scheme/slib-3.1.1-r1 ~dev-scheme/slib-3.1.1-r1
i think what PMS should actually say is (modified from PMS, r172, page 33, section 9.2.1): " ... Equal to the specified version, except the revision part of the matching package may be greater **or equal** than the revision part of the specified version ... " this is at least what paludis-0.24.6 implements and should be preferred because it gives the operator a greater expressiveness (how would you say "the same package and version regardless of the revision with the '<' meaning) while it leaves the meaning of the operator intact if used without PR.
(In reply to comment #9) > So far as I can see, there's exactly one package in the tree where this > matters, and it looks like it's after the behaviour described in PMS anyway... > > #include <paludis/paludis.hh> > #include <iostream> > [...] > > Gives: > > app-office/gnucash-2.0.5:0::gentoo: ~dev-scheme/slib-3.1.1-r1 > ~dev-scheme/slib-3.1.1-r1 just a side-note: there might also be candidates in the profiles dir...
(In reply to comment #10) > " > ... > Equal to the specified version, except the revision part of the matching > package may be greater **or equal** than the revision part of the specified > version > ... > " No, the "or equal" isn't necessary or useful. We say "may", not "must".
(In reply to comment #12) > No, the "or equal" isn't necessary or useful. We say "may", not "must". Right... now that I know what it means, I've a hard time to imagine how I could have misread this in the first place. But maybe this is exactly the point I should make: Sentences like the above, that are easily understood by people who already know what they are meaning, might still be misread by people who don't, so being overly explicit here and there won't do any harm. Whatever, I don't plan to write an essay about a single damn sentence, nor is it worth to discuss this any further. As far as I'm concerned, feel free to close with ${YOUR_RESOLUTION}.
*** Bug 264587 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The wording in PMS for this is deliberate... Portage's behaviour when -r > is present is silly and illogical; the described behaviour is sensible and > useful. I don't see anything "silly" or "illogical" with ~ meaning something like "approximately equal". Obviously you can define it one way or the other, and both ways are consistent and meaningful. Portage chose to ignore the revision part, so PMS should document it in this way. (In reply to comment #7) > It's nonsensical because it ignores part of the cat/pkg-pv-r -- specifically, > the -r part. If the -r part is important, then there is the = operator. The point of ~ *is* that the -r part is ignored. One could also argue that it is inconsistent to disregard -r only for one and not for both operands of the comparison.
Last time we looked, everything using ~ with a revision in the tree was expecting the documented behaviour, not Portage's behaviour. This strongly suggests Portage should be fixed.
(In reply to comment #16) > Last time we looked, everything using ~ with a revision in the tree was > expecting the documented behaviour, not Portage's behaviour. Which were how many ebuilds? Exactly *one* according to comment #9. And this is gone from the tree. AFAICS, nothing in the current tree is using ~ together with -r. (Which is no wonder since it would break either Portage or Paludis.)
In my opinion PMS should be documenting what portage implements as EAPI-0. It is not up to individuals that are not Gentoo developers to decide what is nonsensical or not and misdocument things to not match portage behaviour at the time. That said, I see some value in the currently documented behaviour as an EAPI-4 feature, because then we can express ( >=cat/foo-2.0-r2 <=cat/foo-2.0-r9999 )
Since nothing in the tree relies on this anymore, and zmedico kindly committed my repoman patch to avoid it happening in future, I think there's no reason not to change PMS now.
If the PMS wording of this is desired, jam it into eapi3/eapi4 w/ a mention that it's disallowed for <=eapi2... I'd be more inclined to open up '~' so that >=/<= and friends can be used with it also. Specifically such that ~>=dev-util/diffball-1.0-r2 would mean "any version of 1.0, w/ a rev of 2 or higher". GLSA's already have something similar to this- they'd likely benefit from expanded syntax. Syntax is a bit fugly, but so it goes.
Created attachment 356862 [details, diff] Patch for dependencies.tex (In reply to David Leverton from comment #19) > Since nothing in the tree relies on this anymore, and zmedico kindly > committed my repoman patch to avoid it happening in future, I think there's > no reason not to change PMS now. See attached patch.
I see no objections. Pushed.
