Carlo, *NEVER* *EVER* stick an ebuild like libungif-9999 into the tree. You deprecate a package via depends, not via sticking an intentional explossion in the buildplan of anyone who has it. That's not deprecation, that's forcing people to pick up the pieces (even if you provide the info). Remove it.
Brian, apply the wedgie to yourself. I'd like to hear what's wrong with it to make our users aware of the issue and how to fix it. None complained yet and it's much better than our usual blockers (and there is one in the giflib ebuilds) without _any_ information, causing an "intentional explosion" as well. I'd love we had a Portage version providing the means to sort out such issues in a transparent way, but we don't have.
The issue isn't portage here. If a package specifically requires an alternate provider then ligungib, you dep on it. You do *not* intentionally bomb out any libungif user as a method to try and force upgrades. Here's the issue; if you had just removed the damn ebuild, or changed the deps, portage would've either hit the blocker, or continued on it's own. What you've done is made is such that even if a smarter portage were available that unmerged on it's own, it cannot handle this case since it is _not_ represented in the deps. That's also not getting into the fact that again, we do everything in our power to avoid knowingly having ebuilds bail. This is long standing policy, if you don't know it, fine here's the notification. Yes, nifty trick, don't ever do it again. Blockers exist for a reason, improve what we have if it's hindering you but don't go sticking kludges into the tree rather then doing a proper job.
Also, blockers are resolved at dep resolution time instead of merge time. Atleast with a blocker users don't come back to see their merge stopped half way through for no reason.
Removed the package entirely. QA folk, kindly comment. This little trick is massively out of line from what's accepted. That's not commenting on the stabling involved, either.
(In reply to comment #2) > Here's the issue; if you had just removed the damn ebuild, or changed the deps, > portage would've either hit the blocker, or continued on it's own. So removing the package is fine with you, even though it leaves users in dark, why this happens? I value the user information higher, because the complains about missing information about blockers I see all the time. (In reply to comment #3) > Also, blockers are resolved at dep resolution time instead of merge time. > Atleast with a blocker users don't come back to see their merge stopped half > way through for no reason. True, but it's a small low level lib, so it should get noticed quickly and my reasoning why I did so, you can read above.
> So removing the package is fine with you, even though it leaves users in dark, > why this happens? I value the user information higher, because the complains > about missing information about blockers I see all the time. And lots of users value not having emerge implode half way through an emerge. I personally value the ability to deal with blockers more intelligently long term, which your little trick in no way enables. Regardless, there are established mediums for dissemination of info. -dev ml, forums notices, hell, news notices. Masking it also, and letting it sit with the notice. This is *standard* practice that everyone else does. Hell, depending on libgif rather then libungif, and having libgif block libungif solves this problem and has existed for *quite* some time. > (In reply to comment #3) > > Also, blockers are resolved at dep resolution time instead of merge time. > > Atleast with a blocker users don't come back to see their merge stopped half > > way through for no reason. > > True, but it's a small low level lib, so it should get noticed quickly and my > reasoning why I did so, you can read above. You're reaching for justification for a kludge; as made clear, there are none in this case. As stated, this is a gross QA violation, do not do it again, period.
And... so we make it clear *never* *ever* *ever* to do this again, your lil hack has actively fucked up the following ebuilds app-editors/emacs/emacs-21.4.ebuild dev-dotnet/libgdiplus/libgdiplus-1.0.5-r3.ebuild dev-dotnet/libgdiplus/libgdiplus-1.0.5-r4.ebuild dev-dotnet/libgdiplus/libgdiplus-1.0.6.ebuild gnustep-base/gnustep-gui/gnustep-gui-0.9.4-r1.ebuild gnustep-base/gnustep-gui/gnustep-gui-0.9.4.ebuild media-gfx/fbi/fbi-1.31.ebuild media-gfx/fbida/fbida-2.03.ebuild x11-wm/windowmaker/windowmaker-0.80.2-r2.ebuild x11-wm/windowmaker/windowmaker-0.80.2-r4.ebuild They all still rely on ungif in some measure (I should know, since I just broke the depgraph for them).
not a big deal seeing as how they've been broken for quite a while due to the blockers i put in place
Please calm down, Brian. For all these ebuilds, newer ones are in place and stable as necessary. So there's nothing broken.
(In reply to comment #9) > Please calm down, Brian. For all these ebuilds, newer ones are in place and > stable as necessary. So there's nothing broken. So... why not have the ebuilds yoinked rather then inserting v9999. Yes, bit pissed off at finding it sitting there for reasons stated above. Meanwhile, ebuilds still bound are either removed, or masked (and bugs filed).
(In reply to comment #10) > Meanwhile, ebuilds still bound are either removed, or masked (and bugs filed). > You may do it this way. I tend to wait a while, having the issue solved by itself, then revisting it. You removed the package without caring - not me.
> You may do it this way. I tend to wait a while, having the issue solved by > itself, then revisting it. And there's part of the core reason I'm pissed off. Carlo, you left this mess sitting in the tree- horkage that was still accessible. "Tend to wait a while" ? Inserting an ebuild that bombs out in the tree doesn't qualify. All you've done thus far is excuse doing this- you *know* this is not how things are done. The issue was not solved, it was shoving borkage down on anyone who had nonstandard visibility filters or the misfortune of having ungif merged, rather then using _established_ methods of handling this. If you can't see this, then I'd suggest you do some digging and see how others handle this. > You removed the package without caring - not me. Wrong. Surprisingly, did scan for it already (interpret that as incompetence for missing those ebuilds if you like). Screwups happen, question is intention- dumb ass mistakes are acceptable within limits, taking short cuts rather then the proper route isn't.
(In reply to comment #12) > And there's part of the core reason I'm pissed off. > > Carlo, you left this mess sitting in the tree- horkage that was still > accessible. "Tend to wait a while" ? Inserting an ebuild that bombs out in > the tree doesn't qualify. This has nothing to do with this extra ebuild, which I did add out of courtesy to get users informed. You could simply have removed this ebuild, instead the whole package. That you're pissed is nothing I can change or do care about. > All you've done thus far is excuse doing this- you *know* this is not how > things are done. The issue was not solved, it was shoving borkage down on > anyone who had nonstandard visibility filters or the misfortune of having ungif > merged, rather then using _established_ methods of handling this. If you can't > see this, then I'd suggest you do some digging and see how others handle this. > > > You removed the package without caring - not me. > Wrong. Surprisingly, did scan for it already (interpret that as incompetence > for missing those ebuilds if you like). Screwups happen, question is > intention- dumb ass mistakes are acceptable within limits, taking short cuts > rather then the proper route isn't. > Blah, blah. I still think it's more important to make the user aware of what's happening. I can accept other reasoning, though. Speaking about dumb ass mistakes: How does it come, that you scanned the tree and later accuse me having broken the depgraph of some irrelevant ebuilds, while you were the one who removed the package? This doesn't fit.
(In reply to comment #13) > Blah, blah. I still think it's more important to make the user aware of what's > happening. I can accept other reasoning, though. Speaking about dumb ass > mistakes: How does it come, that you scanned the tree and later accuse me > having broken the depgraph of some irrelevant ebuilds, while you were the one > who removed the package? This doesn't fit. > Alright, lets stop this stupidity already. Carlo, you screwed up by putting an ebuild like that into the tree. Don't do it again. Lets stop the blame game already.
(In reply to comment #14) > (In reply to comment #13) > > Blah, blah. I still think it's more important to make the user aware of what's > > happening. Use alternate routes then invalid ebuilds in the tree. News glep, news items on w.g.o, forums, dev announcements, etc. > I can accept other reasoning, though. Speaking about dumb ass > mistakes: How does it come, that you scanned the tree and later accuse me > having broken the depgraph of some irrelevant ebuilds, while you were the one > who removed the package? This doesn't fit. You're missing the fact portage tries to update packages. Thus, anyone who *had* the ebuild merged, or portage tried to merge the package, resulted in it bailing out every time. An intentional bail built into the depgraph. Basically, execution of that graph is a borkage; my removal of the package just resulted in portage bailing during dgraph calc, rather then execution. This is *exactly* why we don't do crap like this in the tree, and use blockers. Because it can be dealt with up front, rather then (potentially) hours down the line.
(In reply to comment #14) > Alright, lets stop this stupidity already. Carlo, you screwed up by putting an > ebuild like that into the tree. Don't do it again. Lets stop the blame game > already. I only wanted to point out, that I'm not resposible for the consequences of removing the whole package. Brian did that.
> I only wanted to point out, that I'm not resposible for the consequences of > removing the whole package. Brian did that. Alright, now this is getting old. Inability to resolve at calculation time I introduced (and fixed)- the inability to execute resolution you introduced via this trick. Instead of bombing out in execution, you should've cleaned up the deps and removed the potential- exact end result of what I did (note I'm stating end result- already made it clear my initial execution sucked, something that isn't in question nor in need of discussion). What's going to end this bug is when you make it clear you're not going to do this again- normally I'd just ignore someone doing something idiotic, but you seem hell bent on absolving any responsibility for this beyond stating your way is better. Restating it hopefully for the final time, doing what you did bombs out execution for users- yay, you have a custom message rather then a blocker message. Rather then changing the visibility filters involved, your trick broke execution for all users who hit it- this is not valid (regardless of your opinion), as I've stated repeatedly don't do it. Portage has no way to deal with it, it is a built in fail to any long running emerge (screws with users), and other methods exists to deal with this scenario (namely, doing the work and cleaning up the tree rather then dumping a bomb into the tree to nudge users instead of devs). We clear on that? It's not a valid trick. Point at my fuck up in cleaning up the mess all you want, but I want confirmation you're not going to get 'creative' next time around and pull this again since you don't seem even willing to admit this was invalid in light of tree policy/conventions. Comments thus far from you in this bug have given no indication that you're not going to violate tree policy and repeat this- if we're clear on it that's it's not valid (thus don't do it), I'll gladly shut up.
