Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.