With both subversion (with WebDAV capabilities) and davfs2 installed, neon gets up- and downgraded with system update, between 0.25 and 0.26. Obviously this will not do, especially considering subversion seems to work with neon-0.25 while davfs2 does not even compile with neon-0.26, at least for now. Attached you will find a patch for the subversion ebuild which removes the strict requirement for version 0.26 of neon.
Created attachment 91165 [details, diff] subversion-1.3.2-r1.ebuild-neon.patch
Kindly see Bug 139324.
Well, that bug has not exactly been fixed either - there should have been a blockade, not never-ending up- and downgrades of neon (which by the way are not a new problem with this library, judging from some of older Bugzilla reports involving it). That aside, kindly note that even though having subversion stop demanding the 0.26 branch of neon does work around the present issue (of the present number of 12 portage ebuilds depending on neon, only subversion and rapidsvn depend specifically on this branch and they both seem to work fine with 0.25 - whereas the same cannot be said about 0.26 and all of the remaining ebuilds, not to mention the fact subversion itself had to be patched to work with this branch), this demand is not the bug I have reported... Let me rephrase and restate: the repository has been made inconsistent and as a result of that action behaves now in an unpredictable way, i.e. stays in an installation loop instead of blocking the offending package. The former can always happen, as ebuild developers are after all just human, but the latter definitely should NOT be present in a product meant for production - and since we're talking about portage here and not ebuilds it installs, my complaint has nothing to do with using the unstable branch(es). This is not the first issue like this I have encountered, for instance the current setiathome ebuild would keep having boinc oscillate between the 4 and 5 branch even though the former works fine with both, technically shouldn't allow the upgrade in the first place and, all the more interesting, was the only package in my system actually depending on boinc. That one could be resolved with a simple manual mask with no functionality losses; this time it's either editing the ebuild to get rid of the stupid dependency or compiling subversion without WebDAV support. Still, be it an easier or a more difficult scenario it is still somewhat annoying to have to mess around with upgrades this way ("let's see, can I unmask or deoverlay this package today... no, still broken... oops, turns out THIS one got fixed almost three months ago!"). I think we should definitely either work more on slots (speaking more of neon here, I see in another bug report that the only thing preventing version 0.26 from getting slotted is an okay from the ebuild's maintainer) or consider some more philosophical changes to portage which would make it more self-sustaining. Possibly both, as perhaps slots aren't understood by ebuild developers well enough.
Right, I've just run some more tests and it seems that while the problem in general remains present and valid, it is NOT subversion which causes oscillations... I have set USE=nowebdav on subversion, I have applied my patch and I have regenerated the metadata, but even so as long as neon-0.26 is not masked, emerge does enter the cycle even though one of the only two ebuilds in the system which depend on neon doesn't specify the version (net-misc/cadaver-0.22.2) and the other explicitly wants <0.26 (net-fs/davfs2-0.2.8). (BTW. neon dependencies have to be corrected much more thoroughly, it seems: I've had a closer look at the other ebuilds depending on it and it turns out quite a lot of them demand one particular version different between various ebuilds, in some cases as old as 0.24. I was REALLY lucky to have hit the issue with only cadaver and davfs2 installed) Baffled by the above, I dug into the issue a bit more and I may have found the indirect cause of the problem - davfs2 has got neon in DEPEND, but not RDEPEND. Having noticed this I had a look at the boinc/setiathome pair and sure enough, it's the same thing there. Looks like there may be a need to fix something in portage itself... Last but not least, davfs2 is in fact wrong not to have neon in RDEPEND, as mount.davfs is dynamically linked against the library. I really should go to sleep soon so I'll settle for stating this fact at the moment, but unless someone is so kind to fix the ebuild for me I'll do that tomorrow and see if it fixes this bug.
p.mask it, nothing we could do about it in ebuilds. *** This bug has been marked as a duplicate of 48195 ***
One last post here, was going to send it last night but the server ceased to respond so I copied it to a file for later. Maybe these observation will prove useful to somebody. * * * Couldn't sleep, so I've already had a look at it. The good news is that it's quite easy to see what is wrong: linux-mod.eclass completely messes up inter-relations between RDEPEND and DEPEND. The bad news - so far I am out of my depth policy-wise when it comes to messing with eclasses, so unless you point me to some crash course in here, I won't be able to fix it any time soon. Not in a proper way, at least - as I have found out, the universally hated 'RDEPEND="${DEPEND}"' line makes the dependencies closer to what they should be like (except unmasking neon-0.26 still makes the system want to upgrade... aww, screw it :-/ It's a production system, I don't have time to uninstall and reinstall stuff to make sure everything I've changed in dependencies has been propagated across portage). Finally, something unrelated to the problem in question but also worth correcting while the ebuild is being messed with: this version of davfs2 doesn't link against SSL and TLS libraries on its own any more, using whatever neon has been compiled with instead (which among other things could lead to such interesting phenomena as emerge installing libxml2 prior to davfs2 only to have it use expat later). As a result, it is safe to remove dependencies on the two aforementioned libraries from *DEPEND and the flag 'ssl' from IUSE and ebuild contents.
