Portage suddenly switching to ~amd64

[FastTurtle]

I'm using the amd64/13.0/no-multilib and in running an emerge -pv virtualbox it suddenly wants to pull in Vbox 4.2.1 w/o it being unmasked in package.keywords nor do I have any flags set for vbox in package.use
My make.conf settings

[John R. Graham]

Side comment: your CFLAGS are borked two ways. First, "-o0" is incorrect to select optimization: that should be a capital O. Second, unless you're building for debugging—and the absence of other CFLAGS (principally "-ggdb") convinces me you're not—"-O0" is a bad idea. At least use "-Os"; in most cases -O2 is recommended. What are you trying to accomplish?

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[FastTurtle]

I posted the entire make.conf section to show I was not on the ~arch setting. Thus the reason I was questioning my conclusion on what portage was showing, which you didn't answer with your side-comment about the unimportant Optimization flag - if it's wrong, it's ignored due to the defaults set by each package. Isn't that the correct behaviour of portage? Ignore incorrect settings and use the defaults specified in the package or profile?

If my thinking is correct, then we have a portage bug that needs to be addressed as it should have shown the stable version 4.1.24 and the keyword/profile changes needed to support it then any changes to show what would be needed for the ~arch version. To my thinking, Portage should never default to the ~arch w/o showing what the Stable version requires unless the system is on the testing/unstable branch to begin with - Thus the bug report that is going to be filed in regards to improper behaviour as I can no longer trust that portage wont upgrade me to the ~amd64 branch w/o warning and voiding all of my make.conf effort and if that happens, Gentoo will be no better then MS for deciding it knows better then I Do What I WANT FROM MY COMPUTER

[TomWij]

/usr/portage/profiles/features/64bit-native/package.mask masks the entire virtualbox; therefore to get it it will try to satisfy it by trying to change your configuration, that way it suggests the unstable keyworded virtualbox. Since it mentions "# Mask packages that rely on amd64 multilib" in that file I don't think that merging this would work at all...

[FastTurtle]

and I consider that improper behaviour as portage isn't stating why it's wanting the ~arch as it should.

As I said in reply to John: Portage should have shown a Masked Package for the 4.1.24 and why it was masked before showing the ~amd64 version. In other words, bad behaviour that needs to be fixed.

Yes I've seen where a stable package couldn't satisfy the needs and have gotten an explanation why. Right now, I can't trust portage not to suddenly upgrade me to the ~arch branch w/o warning/explaination and that makes gentoo unusable.

Thankfully, I always check what portage is going to do with the -pv flag in case of blockers and circular dependencies. Much safer then blindly trusting the installer/package manager as Window Users are forced to.

[Ant P.]

[John R. Graham]

[FastTurtle]

Ant P.

As I stated, Portage did not pass the proper "Package Masked" information and immediately showed the ~amd64 packages. This makes it completelyimproper behaviour as Portage Should Never Never simply tell you that you need the ~arch branch of a package w/o showing a "Packaged Masked" message and yes I've had this happen several times while installaling. Even if there's no explanation as to why a package is masked, it at least warns you that something is wrong.

In this case, no warning. Meaning I can not trust portage to function correctly as I do not have ~arch set in make.conf. Will portage suddenly switch me to the ~* branch and unmask all of the hard masked packages? That's the damn reason when this happens that it's considered a BUG.

John:

In the case of an incorrectly formated command, portage ignores it - that would be the case if it was actually the "o0 that you saw - cut-n-paste issue probably.

in the case of a Wrong Build Option, should portage have already filtered bad ones out if it'll break the build?

Have you ever dived into the GCC Optimization Docs as I have? What the different levels actually mean? Unroll-Loops and such are just some of them. The Zero flag tells the toolchain to do just that, No Optimizations at all. If a package wont build with no optimizations then it shouldn't be in portage as it's incomplete. It's that simple. Before you state that I haven't a clue, check the comparison page on the GCC website for what each Optimization flag does because if portage isn't following GCC's process, then Gentoo is no longer of use to anyone since it's not following any recognized standard.

As I stated in the earlier post, the only thing I changed in regards to the Optimizatio flag is the 2 became a 0 (zero) so what you're seeing is a cut-n-paste error as I just completed a -e world rebuild w/o problem overnight (had some new flags that --newuse wasn't seeing and yes I may have typo'd the command). As in my original post, the damn o/O issue was and still is immaterial to my original question so why did you bother to post/point it out uselessly?

TimWij:

I just filed the bug report for the unexpected behavour - and yes it's a bug to my thinking as Portage Should never just suggest ~arch apps unless the user is using ~arch in make.conf. Throw me a Masked Package message with the reason before suggesting the ~arch solution.

[John R. Graham]

Let me just apologize for wasting your time and leave it at that, then.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

Portage cannot protect you from every possible mistake you may try to make. You can argue that a package ought to build with -O0 if you like. I would argue that every package ought to cross-compile readily and according to a standard procedure. Some Gentoo developers agree with that, but that does not mean that the entire tree actually is able to do so.

[FastTurtle]

True nor should it but as I stated twice to John: His post never addressed my question as to whether portage goofed or was the response I'd seen expected.

The response from TomWij actually did address and clairify things enough for me to file a bug report as portage should never ever suggest ~arch packages w/o telling me that the package I want is masked. In fact, as far as I'm concerned, portage should never suggest ~arch packages unless the system is on the ~arch.

As to seeing a masked package message, I've seen a couple in regards to specific packages since I'm running a pure 64bit system - Package Masked by profile messages happen and give me enough information to figure out why but in the case of Virtualbox, portage didn't and if portage continues this practice, then the trust factor is completely destroyed.

In the handbook and and portage guides, users shouldn't edit any of the package mask/unmask files in the portage directory. We are to use the /etc/portage location as those wont be replaced/borked during the next portage sync as their protected. This is by design and I actually agree it's a good design choice.

John: The problem with your response is that you never answered the original question about suddenly seeing the ~virtualbox being expected behaviour. Instead you went off on a SIDE NOTE (your post) about the optimization flag. According to the guides, if the entry isn't in the right format (which a lower case "o" is) then portage and the toolchain would simply ignore it and the default for the profile/pacakge would come into play. The system is designed this way to provide a tested/stable build even when the user screws up with a typo. It is not supposed to help when a user goes out of their way to use -O38 to rice the system and is unsupported.

[qoute]Anyone have an idea what 's going on?

Well reading the emerge output, it looks like it maybe a no-multilib issue (Pure 64bit) that's pulling in the 4.2.10 build and that of course needs an accept license change
[/quote]

That's the question you never answered. Sure I may have figured it out but I wasn't sure and that's why I got a bit short with you. Thankfully TomWij came to the rescue and confirmed that I was correct, which forced the bug report as that is completely unacceptable behaviour. I'll say it again, portage should never ever suggest the ~arch branch w/o the system being on the ~arch branch and if there is a package mask in place, it absolutely needs to tell us "Package Masked by" what ever reason on the system. That's critical to retain the sys-admin/users trust in portage.

If and when I screw up, I know who to blame and it aint Gentoo or the Devs at that time. It falls squarely on my shoulders and yes I've screwed up royally at times and completely borked a system to the point it was faster to reinstall then trying to fix what I broke.

[John R. Graham]