This ebuild imho need a dependency added: =gnome-extra/gtkhtml-3.10* is needed there, do avoid upgrade/downgrade problems. kind regards
This (In reply to comment #0) > =gnome-extra/gtkhtml-3.10* is needed there, do avoid upgrade/downgrade > problems. This won't avoid any upgrade/downgrade problems, sorry. *** This bug has been marked as a duplicate of 48195 ***
Why not - i added this to my local overlay and it worked - so why do you think thats wrong? kind regards
(In reply to comment #2) > Why not - i added this to my local overlay and it worked - so why do you think > thats wrong? Did you read the bug this bug is a duplicate of?
Yeah, but what has depclean to do with my bugreport - didnt see the "duplicate" sense. At ebuild only gtkhtml up to 3.8 is written as dependeny with equality. As far as i know, 3.10 is also suitable, so i thought it have to be added to the DEPEND in the ebuild, am i wrong? kind regards
(In reply to comment #4) > Yeah, but what has depclean to do with my bugreport - didnt see the "duplicate" > sense. > At ebuild only gtkhtml up to 3.8 is written as dependeny with equality. As far > as i know, 3.10 is also suitable, so i thought it have to be added to the > DEPEND in the ebuild, am i wrong? Uhm? Depclean? The other bug has "Dep calculation does not use installed package information" in summary. Translated: portage won't use the dependencies of already installed package for future upgrades/dependency calculation for other ebuilds. Meaning: =gnome-extra/gtkhtml-3.10* gets completely useless at the very moment you emerge gtkhtml-sharp. You'll *still* get upgrade/downgrade cycle once you emerge any other ebuild that depends on gnome-extra/gtkhtml and has no such restriction or has =gnome-extra/gtkhtml-3.8* or anything else.
Yeah thats right. And how to solve this? My solution is, that for gtkhtml-sharp, the dependency have to be updated to match the new package dependency which is available. Of cause, for any other package which has the same "bug", this must be done too and might be reported from others. But ok - i've searched a little bit, theres a gnome bug there: http://bugs.gentoo.org/show_bug.cgi?id=126700 Sounds like the same solution to me - or am i wrong too here? kind regards
(In reply to comment #6) > My solution is, that for gtkhtml-sharp, the dependency have to be updated to > match the new package dependency which is available. That won't solve anything wrt upgrade/downgrade cycles, I've already tried to explain three times, won't do it any more. > Of cause, for any other package which has the same "bug", this must be done too > and might be reported from others. It's not an ebuild bug, it's a portage bug. See above. > http://bugs.gentoo.org/show_bug.cgi?id=126700 > > Sounds like the same solution to me - or am i wrong too here? Ask the developer who filed that reminder bug how is he going to fix that bug. It can't be fixed via ebuild dependencies. The only proper fix is to fix the package that depends on gtkhtml to not require a particular version of a dependency *only*, but rather to work with >=x.y type of dependencies.
Ok - thats a minor difference to mine, then this bugreport should be changed in meaning to: gtkhtml-sharp-2.4.0 should have changed the particular dependencie to >= . Should i file a new bug for that or what now, i understand your solution, but >= is like adding all avaiable paritcular versions greater than the minimum required one to the ebuild, so in my meaning, the bug which is still there have to be solved anyway - or should i add this ebuild "bug" to the duplicate thread? The fix to fix it you have mentioned, that is what i want to have said with this bugreport. If it is done through >= or adding the particular new version, the result to me is the same, for the particular ebuild who depends on some other. kind regards
Please, use Bug 126700 for whatever questions you have wrt this. This bug is exactly the same as Bug 126700. You can't simply solve this bug by adding any type of deps, the dependencies need to *work*. If an ebuild has =3.8* in dependencies, it means that it won't compile/work with any other version. *That* is the real bug that needs to be fixed. Messing with dependencies won't solve it in any way; =3.8* type of deps produces upgrade/downgrade cycles. End of story.
I did not add ANY dependency, did you read the ebuild? I guess you didn't read. At ebuild there is: DEPEND="${DEPEND} =dev-dotnet/gnome-sharp-${PV}* =dev-dotnet/art-sharp-${PV}* || ( =gnome-extra/gtkhtml-3.8* =gnome-extra/gtkhtml-3.6* =gnome-extra/gtkhtml-3.2* =gnome-extra/gtkhtml-3.0.10* )" So it works with all of these, and it WORKS with 3.10.* too. I think i dont have to understand this senseless discussion, i did not made the ebuild and only want to report a fix, couldn't imagine that this is so difficult. kind regards
(In reply to comment #10) > I did not add ANY dependency, did you read the ebuild? I guess you didn't read. Sure I do read. > At ebuild there is: > DEPEND="${DEPEND} > =dev-dotnet/gnome-sharp-${PV}* > =dev-dotnet/art-sharp-${PV}* > || ( > =gnome-extra/gtkhtml-3.8* > =gnome-extra/gtkhtml-3.6* > =gnome-extra/gtkhtml-3.2* > =gnome-extra/gtkhtml-3.0.10* > )" > > So it works with all of these, and it WORKS with 3.10.* too. Yeah, so it's exact duplicate of Bug 126700. So, kindly move there, please... The dependencies issue is known, someone will eventually fix it I hope. If you are complaining about upgrade/downgrade cycles, it's what Bug 48195 is about. And - the above type of dependencies is *exactly* what's *causing* these cycles. The above dependencies are stupid, and will be equally stupid whether you add =3.10* to the list or not. They are producing upgrade/downgrade cycles. You'll get the exact same up/down cycle once gtkhtml gets another version bump, or ... or... blah, won't repeat what's been repeatedly said above. I've been trying to explain this for far too long, but you don't understand. So, for the last time - you'd get no upgrade/downgrade cycles if the darned gtkhtml-sharp ebuild simply stated >=gnome-extra/gtkhtml-3.0.10 instead of listing bunch of gtkhtml versions starting with =3.0.10* there for whatever weird reason. Move this debate to Bug 126700 and ask there why the ebuild is using such stupid dependencies. End of story, no need for further comments. This is duplicate of two bugs listed above. CLOSED. Thanks.