Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Yohan Pereira
On Monday 25 October 2010 9:50:30 pm Allan Gottlieb wrote:
> Yes?

yes

-- 
- Yohan Pereira.



Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Allan Gottlieb
Alan McKinnon  writes:

> Apparently, though unproven, at 02:26 on Monday 25 October 2010, Allan 
> Gottlieb did opine thusly:
>
>> Alan McKinnon  writes:
>> > Just because you're paranoid doesn't mean they're NOT out to get you :-)
>> > 
>> > Or in this case, it doesn't mean it's not justified. I now have buildpkg
>> > enabled for @system - everything else I can re-run emerge to fix.
>> 
>> Does this mean for portage -2.1.9.22 you advocate
>> FEATURES="buildsyspkg"
>> in make.conf?
>> 
>> If so is that the correct line or do we need
>> FEATURES="buildsyspkg sandbox"
>> 
>> I find the man page wording a little unclear and its warning about an
>> error serious.
>
>
> You're adding extra stuff into the mix and confusing the issue. Forget about 
> sandbox in the context of this thread, just take whatever you have in 
> FEATURES 
> and add buildsyspkg to it. That's it, nothing more, nothing less.

OK.  Since currently it is empty, I just need
FEATURES=" buildsyspackage"
i.e, I do NOT need to include sandbox.

Yes?
allan



Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Alan McKinnon
Apparently, though unproven, at 15:09 on Monday 25 October 2010, Bill Longman 
did opine thusly:

> On 10/25/2010 01:24 AM, Alan McKinnon wrote:
> > Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did
> > 
> > opine thusly:
> >> Then again, Alan knows
> >> Gentoo pretty well and may know that he doesn't need sandbox.
> > 
> > Once for fun I build a gentoo system in VirtualBox and left sandbox out
> > by accident.
> 
> Where did you leave it out? Or do you mean you "took" it out with a
> "-sandbox"?

Yes, I took it out with "-sandbox". I was being pathetic that day and 
attempted a pathetic solution. The results were ... pathetic too !

-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Bill Longman
On 10/25/2010 01:24 AM, Alan McKinnon wrote:
> Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did 
> opine thusly:
> 
>> Then again, Alan knows 
>> Gentoo pretty well and may know that he doesn't need sandbox.
> 
> 
> Once for fun I build a gentoo system in VirtualBox and left sandbox out by 
> accident.

Where did you leave it out? Or do you mean you "took" it out with a
"-sandbox"?

> The results were ... awful. Bad stuff happened. It was so bad I forgot all 
> the 
> details and started over.
> 
> 




[gentoo-user] Preventing a package from being updated -> OT parallel-fetch

2010-10-25 Thread KH
Am 25.10.2010 04:36, schrieb Dale:
> FEATURES=" buildpkg sandbox fixpackages parallel-fetch --keep-going"

Hi,

parallel-fetch is default and no need to list it in make.conf any more.
I notices when I had to add -parallel-fetch to one of my boxes.

kh




Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Fatih Tümen
On Mon, Oct 25, 2010 at 5:36 AM, Dale  wrote:
> FEATURES=" buildpkg sandbox fixpackages parallel-fetch --keep-going"

I thought --keep-going goes into EMERGE_DEFAULT_OPTS, no?

--
   Fatih



Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Alan McKinnon
Apparently, though unproven, at 04:36 on Monday 25 October 2010, Dale did 
opine thusly:

> Then again, Alan knows 
> Gentoo pretty well and may know that he doesn't need sandbox.


Once for fun I build a gentoo system in VirtualBox and left sandbox out by 
accident.

The results were ... awful. Bad stuff happened. It was so bad I forgot all the 
details and started over.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-25 Thread Alan McKinnon
Apparently, though unproven, at 02:26 on Monday 25 October 2010, Allan 
Gottlieb did opine thusly:

> Alan McKinnon  writes:
> > Just because you're paranoid doesn't mean they're NOT out to get you :-)
> > 
> > Or in this case, it doesn't mean it's not justified. I now have buildpkg
> > enabled for @system - everything else I can re-run emerge to fix.
> 
> Does this mean for portage -2.1.9.22 you advocate
> FEATURES="buildsyspkg"
> in make.conf?
> 
> If so is that the correct line or do we need
> FEATURES="buildsyspkg sandbox"
> 
> I find the man page wording a little unclear and its warning about an
> error serious.


You're adding extra stuff into the mix and confusing the issue. Forget about 
sandbox in the context of this thread, just take whatever you have in FEATURES 
and add buildsyspkg to it. That's it, nothing more, nothing less.

-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-24 Thread Dale

Allan Gottlieb wrote:

Alan McKinnon  writes:

   

Just because you're paranoid doesn't mean they're NOT out to get you :-)

Or in this case, it doesn't mean it's not justified. I now have buildpkg
enabled for @system - everything else I can re-run emerge to fix.
 

Does this mean for portage -2.1.9.22 you advocate
FEATURES="buildsyspkg"
in make.conf?

If so is that the correct line or do we need
FEATURES="buildsyspkg sandbox"

I find the man page wording a little unclear and its warning about an
error serious.

thanks
allan

   


This is mine.

FEATURES=" buildpkg sandbox fixpackages parallel-fetch --keep-going"

It has been that way here for a pretty long while and no problems that I 
know of.  According to the man page, you should have sandbox in there as 
well.  I think Alan was showing what could be added but not all the 
options that are available and should be there.  Then again, Alan knows 
Gentoo pretty well and may know that he doesn't need sandbox.


Just thought I would share a example that is in use and appears to work.

Dale

:-)  :-)



Re: [gentoo-user] Preventing a package from being updated

2010-10-24 Thread Allan Gottlieb
Alan McKinnon  writes:

> Just because you're paranoid doesn't mean they're NOT out to get you :-)
>
> Or in this case, it doesn't mean it's not justified. I now have buildpkg 
> enabled for @system - everything else I can re-run emerge to fix.

Does this mean for portage -2.1.9.22 you advocate
FEATURES="buildsyspkg"
in make.conf?

If so is that the correct line or do we need
FEATURES="buildsyspkg sandbox"

I find the man page wording a little unclear and its warning about an
error serious.

thanks
allan



Re: [gentoo-user] Preventing a package from being updated

2010-10-24 Thread Alan McKinnon
Apparently, though unproven, at 13:50 on Saturday 23 October 2010, daid kahl 
did opine thusly:

> > Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with
> > this automagically (I *think* it does these days and 2.2 definitely
> > does) but if not just
> > 
> > emerge -C shadow ; emerge -1 shadow
> > 
> > then emerge -avuND world.
> > 
> > No good technical reason for doing shadow first apart from getting it
> > over and done with while you watch and confirm it works fine. Then do
> > world and wander over to the kettle letting portage go on with doing
> > it's thing unattended
> 
> For my own comfort, on a case like this, if I didn't have the portage
> FEATURE buildpkg or buildsyspkg turned on, I'd make sure that was on
> and that I had a functional backup of shadow to install from binary,
> in case something went very wrong.  But I tend to be extremely
> cautious in terms of how I maintain my system, and a lot of that
> caution is just paranoia.

Just because you're paranoid doesn't mean they're NOT out to get you :-)

Or in this case, it doesn't mean it's not justified. I now have buildpkg 
enabled for @system - everything else I can re-run emerge to fix.

After watching portage break python *twice* exactly a year apart, watching the 
exciting developments in python-3, after some horrendous shadow breakage 3 
years ago and the convoluted upgrade path for bash 2 years ago, and someone's 
b0rked commit of glibc-2.12 to the tree quite recently, I feel entirely 
justified in keeping binary copies of @system around.

It long ago stopped being paranoia and started being good old common sense 
(right up there with backups).


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-23 Thread Allan Gottlieb
daid kahl  writes:

>> Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with this
>> automagically (I *think* it does these days and 2.2 definitely does) but if
>> not just
>>
>> emerge -C shadow ; emerge -1 shadow
>>
>> then emerge -avuND world.
>>
>> No good technical reason for doing shadow first apart from getting it over 
>> and
>> done with while you watch and confirm it works fine. Then do world and wander
>> over to the kettle letting portage go on with doing it's thing unattended
>
> For my own comfort, on a case like this, if I didn't have the portage
> FEATURE buildpkg or buildsyspkg turned on, I'd make sure that was on
> and that I had a functional backup of shadow to install from binary,
> in case something went very wrong.  But I tend to be extremely
> cautious in terms of how I maintain my system, and a lot of that
> caution is just paranoia.

Thanks for the advice.  I do use quickpkg as well.

allan



Re: [gentoo-user] Preventing a package from being updated

2010-10-23 Thread Allan Gottlieb
Alan McKinnon  writes:

> Apparently, though unproven, at 05:13 on Saturday 23 October 2010, Allan 
> Gottlieb did opine thusly:
>
>> Now I have masked mesa-7.8.2 downgrading to 7.7.1, which necessitated a
>> downgrade of xorg-server to 1.7.7-r1 (latest stable), which necessitated
>> a downgrade of xinit to 1.2.1.
>> 
>> Thus my emerges now generate msgs that updates to xorg-server and xinit
>> are being skipped due to unsatisfied dependencies.
>> Other than this, the emerges perform normally and the system runs well.
>> 
>> I could mask the newer versions of xorg-server and xinit and possibly
>> prevent the emerge messages, but I am leaning toward leaving it as it is.
>> This way when mesa is updated (to a hopefully fixed version) everything
>> should update automatically.
>> 
>> Does that sound reasonable.
>
> Yes, that will work fine. You'll just have to tolerate those messages in the 
> interim, but you know they are there and why. Nothing will break because of 
> it.

Thanks.
allan



Re: [gentoo-user] Preventing a package from being updated

2010-10-23 Thread daid kahl
> Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with this
> automagically (I *think* it does these days and 2.2 definitely does) but if
> not just
>
> emerge -C shadow ; emerge -1 shadow
>
> then emerge -avuND world.
>
> No good technical reason for doing shadow first apart from getting it over and
> done with while you watch and confirm it works fine. Then do world and wander
> over to the kettle letting portage go on with doing it's thing unattended

For my own comfort, on a case like this, if I didn't have the portage
FEATURE buildpkg or buildsyspkg turned on, I'd make sure that was on
and that I had a functional backup of shadow to install from binary,
in case something went very wrong.  But I tend to be extremely
cautious in terms of how I maintain my system, and a lot of that
caution is just paranoia.

~daid



Re: [gentoo-user] Preventing a package from being updated

2010-10-23 Thread Alan McKinnon
Apparently, though unproven, at 05:13 on Saturday 23 October 2010, Allan 
Gottlieb did opine thusly:

> Now I have masked mesa-7.8.2 downgrading to 7.7.1, which necessitated a
> downgrade of xorg-server to 1.7.7-r1 (latest stable), which necessitated
> a downgrade of xinit to 1.2.1.
> 
> Thus my emerges now generate msgs that updates to xorg-server and xinit
> are being skipped due to unsatisfied dependencies.
> Other than this, the emerges perform normally and the system runs well.
> 
> I could mask the newer versions of xorg-server and xinit and possibly
> prevent the emerge messages, but I am leaning toward leaving it as it is.
> This way when mesa is updated (to a hopefully fixed version) everything
> should update automatically.
> 
> Does that sound reasonable.

Yes, that will work fine. You'll just have to tolerate those messages in the 
interim, but you know they are there and why. Nothing will break because of 
it.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-22 Thread Allan Gottlieb
Alan McKinnon  writes:

> Apparently, though unproven, at 16:11 on Friday 22 October 2010, Allan 
> Gottlieb did opine thusly:
>
> [snip]
>
>> Perhaps I should be downgrading xorg-server as well.
>
> Masking mesa-7.8.2 means (per the ebuilds) you will have to drop back to 
> xorg-server-1.7.7-r1. Both are latest stable versions.

See below

>> 
>> Since I would rather have a slow X than an angry portage,
>> I removed the package mask and expected all to be well, but was
>> surprised by the following.  In particular at the end it says there is
>> one block but I don't see any.
>
> [snip]
>
> Here you go:
>
>
>> [blocks b ] > ("> [ebuild U ]  sys-apps/shadow-4.1.4.2-r6 [4.1.4.2-r5] USE="cracklib
>> nls pam -audit (-selinux) -skey" 1,749 kB

I really did look for b's, but didn't see it.  I guess I was looking
near the ] where all the U's are.  Embarrassing, to say the least.
Thanks.

Now I have masked mesa-7.8.2 downgrading to 7.7.1, which necessitated a
downgrade of xorg-server to 1.7.7-r1 (latest stable), which necessitated
a downgrade of xinit to 1.2.1.

Thus my emerges now generate msgs that updates to xorg-server and xinit
are being skipped due to unsatisfied dependencies.
Other than this, the emerges perform normally and the system runs well.

I could mask the newer versions of xorg-server and xinit and possibly
prevent the emerge messages, but I am leaning toward leaving it as it is.
This way when mesa is updated (to a hopefully fixed version) everything
should update automatically.

Does that sound reasonable.

thanks again,
allan



Re: [gentoo-user] Preventing a package from being updated

2010-10-22 Thread Alan McKinnon
Apparently, though unproven, at 16:11 on Friday 22 October 2010, Allan 
Gottlieb did opine thusly:

[snip]

> > package.mask is the right place, but you should add the specific version.
> > Then the system will only upgrade when a newer (hopefully fixed) version
> > arrives.
> > 
> > =media-libs/mesa-7.8.2
> 
> I tried this yesterday with great success.  As mentioned in b.g.o. 7.8.2
> causes slowdowns for many people (including me).
> This system is ~amd64
> 
> But this morning after an eix-sync, my normal update failed

[snip]

>   !!! All ebuilds that could satisfy ">=media-libs/mesa-7.8_rc[nptl=]" have
> been masked. !!! One of the following masked packages is required to
> complete your request: - media-libs/mesa-7.8.2 (masked by: package.mask)
>   /etc/portage/package.mask:
>   # This version of mesa 7.8.2 is rummored to cause slowdown
>   # The previous version 7.7.1 is rummored to be much better
>   # Masking only 7.8.2 so that future (fixed??) versions can be installed
> 
>   (dependency required by "x11-base/xorg-server-1.9.0.902" [ebuild])
>   For more information, see the MASKED PACKAGES section in the emerge
>   man page or refer to the Gentoo Handbook.
> 
>   Would you like to merge these packages? [Yes/No] no
> 
>   Quitting.
> 
>   ajglap gottlieb #
> 
> Perhaps I should be downgrading xorg-server as well.

Masking mesa-7.8.2 means (per the ebuilds) you will have to drop back to 
xorg-server-1.7.7-r1. Both are latest stable versions. Or, you could always 
install the xorg overlay and build the latest git copy of mesa...

> 
> Since I would rather have a slow X than an angry portage,
> I removed the package mask and expected all to be well, but was
> surprised by the following.  In particular at the end it says there is
> one block but I don't see any.

[snip]

Here you go:


> [blocks b ]  (" [ebuild U ]  sys-apps/shadow-4.1.4.2-r6 [4.1.4.2-r5] USE="cracklib
> nls pam -audit (-selinux) -skey" 1,749 kB

Don't worry about it. I'm not sure if portage-2.1.9.20 will deal with this 
automagically (I *think* it does these days and 2.2 definitely does) but if 
not just

emerge -C shadow ; emerge -1 shadow

then emerge -avuND world.

No good technical reason for doing shadow first apart from getting it over and 
done with while you watch and confirm it works fine. Then do world and wander 
over to the kettle letting portage go on with doing it's thing unattended


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Preventing a package from being updated

2010-10-22 Thread Allan Gottlieb
Neil Bothwick  writes:

> On Mon, 18 Oct 2010 13:06:25 +0300, Timur Aydin wrote:
>
>> I am using the ~x86 (testing) version of gentoo linux. After recent
>> updates, my X windows became extremely sluggish and I found out that the
>> problem is related to a new version of mesa (7.8.2 specifically). So I
>> downgraded to version 7.7.1 and my desktop works great again.
>> 
>> Now I want to prevent mesa from being updated until this issue is sorted
>> out upstream. I have looked at package.provide, but that didn't work.
>> Currently, I have placed media-libs/mesa into my
>> /etc/portage/package.mask file and this seems to do the trick. Is this
>> the recommended way for handling this situation?
>
> package.mask is the right place, but you should add the specific version.
> Then the system will only upgrade when a newer (hopefully fixed) version
> arrives.
>
> =media-libs/mesa-7.8.2

I tried this yesterday with great success.  As mentioned in b.g.o. 7.8.2
causes slowdowns for many people (including me).
This system is ~amd64

But this morning after an eix-sync, my normal update failed

  ajglap gottlieb # emerge --keep-going --update --newuse --with-bdeps=y 
--color n world

  These are the packages that would be merged, in reverse order:

  Calculating dependencies... done!
  [nomerge  ] gnome-base/gnome-2.30.2  USE="cdr cups dvdr ldap policykit 
-accessibility -mono" 
  [nomerge  ]  app-crypt/seahorse-2.30.1  USE="ldap libnotify -avahi -debug 
-doc -test" 
  [nomerge  ]   app-crypt/gpgme-1.3.0  USE="-common-lisp -pth" 
  [nomerge  ]app-crypt/gnupg-2.0.16-r2  USE="bzip2 ldap nls -adns -caps 
-doc -openct -pcsc-lite (-selinux) -smartcard -static" 
  [nomerge  ] app-crypt/pinentry-0.8.0-r1  USE="gtk ncurses qt4 -caps 
-static" 
  [ebuild U ]  app-admin/eselect-pinentry-0.3 [0.2] 0 kB
  [nomerge  ] x11-base/xorg-x11-7.4-r1 
  [ebuild U ]  x11-apps/smproxy-1.0.4 [1.0.3] USE="(-debug%)" 111 kB
  [nomerge  ] gnome-base/gnome-2.30.2  USE="cdr cups dvdr ldap policykit 
-accessibility -mono" 
  [nomerge  ]  gnome-base/libgnomeprintui-2.18.6  USE="-doc" 
  [nomerge  ]   x11-themes/gnome-icon-theme-2.30.3 
  [nomerge  ]x11-misc/icon-naming-utils-0.8.90 
  [nomerge  ] dev-perl/XML-Simple-2.18 
  [nomerge  ]  dev-perl/XML-LibXML-1.70 
  [nomerge  ]   dev-lang/perl-5.12.2-r1  USE="berkdb gdbm -build -debug 
-doc -ithreads" 
  [ebuild U ]app-admin/perl-cleaner-2.7 [2.6] 6 kB
  [nomerge  ] gnome-base/gnome-2.30.2  USE="cdr cups dvdr ldap policykit 
-accessibility -mono" 
  [nomerge  ]  app-admin/sabayon-2.30.1 
  [ebuild UD]   x11-base/xorg-server-1.7.7-r1 [1.9.0.902] USE="hal%* ipv6 
kdrive nptl sdl%* xorg -debug% -dmx -minimal -tslib (-doc%) (-static-libs%) 
(-udev%*)" 4,829 kB
  [nomerge  ] gnome-base/gnome-2.30.2  USE="cdr cups dvdr ldap policykit 
-accessibility -mono" 
  [nomerge  ]  gnome-base/gdm-2.20.11  USE="branding consolekit 
gnome-keyring ipv6 pam tcpd -accessibility -afs -debug -dmx -remote (-selinux) 
-xinerama" 
  [nomerge  ]   sys-auth/pambase-20100925  USE="consolekit cracklib 
gnome-keyring sha512 -debug -kerberos -minimal -mktemp -passwdqc (-selinux) 
-ssh" 
  [nomerge  ]sys-auth/consolekit-0.4.2-r3 [0.4.2-r1] USE="pam policykit 
-debug -doc -test" 
  [blocks b ] =media-libs/mesa-7.8_rc[nptl=]" have 
been masked.
  !!! One of the following masked packages is required to complete your request:
  - media-libs/mesa-7.8.2 (masked by: package.mask)
  /etc/portage/package.mask:
  # This version of mesa 7.8.2 is rummored to cause slowdown
  # The previous version 7.7.1 is rummored to be much better
  # Masking only 7.8.2 so that future (fixed??) versions can be installed

  (dependency required by "x11-base/xorg-server-1.9.0.902" [ebuild])
  For more information, see the MASKED PACKAGES section in the emerge
  man page or refer to the Gentoo Handbook.

  Would you like to merge these packages? [Yes/No] no

  Quitting.

  ajglap gottlieb # 

Perhaps I should be downgrading xorg-server as well.

Since I would rather have a slow X than an angry portage,
I removed the package mask and expected all to be well, but was
surprised by the following.  In particular at the end it says there is
one block but I don't see any.

Any help/advice would be appreciated.

allan

  ajglap gottlieb # emerge --keep-going --update --newuse --with-bdeps=y 
--color n world

  These are the packages that would be merged, in reverse order:

  Calculating dependencies... done!
  [nomerge  ] gnome-base/gnome-2.30.2  USE="cdr cups dvdr ldap policykit 
-accessibility -mono" 
  [nomerge  ]  app-crypt/seahorse-2.30.1  USE="ldap libnotify -avahi -debug 
-doc -test" 
  [nomerge  ]   app-crypt/gpgme-1.3.0  USE="-common-lisp -pth" 
  [nomerge  ]app-crypt/gnupg-2.0.16-r2  USE="bzip2 ldap nls -adns -caps 
-doc -openct -pcsc-lite (-selinux) -smartcard -static" 
  [nomerge  ] app-crypt/pi

Re: [gentoo-user] Preventing a package from being updated

2010-10-18 Thread Neil Bothwick
On Mon, 18 Oct 2010 13:06:25 +0300, Timur Aydin wrote:

> I am using the ~x86 (testing) version of gentoo linux. After recent
> updates, my X windows became extremely sluggish and I found out that the
> problem is related to a new version of mesa (7.8.2 specifically). So I
> downgraded to version 7.7.1 and my desktop works great again.
> 
> Now I want to prevent mesa from being updated until this issue is sorted
> out upstream. I have looked at package.provide, but that didn't work.
> Currently, I have placed media-libs/mesa into my
> /etc/portage/package.mask file and this seems to do the trick. Is this
> the recommended way for handling this situation?

package.mask is the right place, but you should add the specific version.
Then the system will only upgrade when a newer (hopefully fixed) version
arrives.

=media-libs/mesa-7.8.2


-- 
Neil Bothwick

WindowError:01B  Illegal error. Do NOT get this error.


signature.asc
Description: PGP signature


Re: [gentoo-user] Preventing a package from being updated

2010-10-18 Thread KH
Am 18.10.2010 12:06, schrieb Timur Aydin:
> Hi,
> 
> I am using the ~x86 (testing) version of gentoo linux. After recent
> updates, my X windows became extremely sluggish and I found out that the
> problem is related to a new version of mesa (7.8.2 specifically). So I
> downgraded to version 7.7.1 and my desktop works great again.
> 
> Now I want to prevent mesa from being updated until this issue is sorted
> out upstream. I have looked at package.provide, but that didn't work.
> Currently, I have placed media-libs/mesa into my
> /etc/portage/package.mask file and this seems to do the trick. Is this
> the recommended way for handling this situation?
> 
> Being a long time gentoo user, I want to do things the right way, so
> just working fine isn't enough :)
> 

Hi,

from man poratage:

"package.mask
A list of package atoms to mask. Useful if specific versions of packages
do not work well for you. For example, you swear by the  Nvidia
drivers,  but  only  versions  earlier  than 1.0.4496. No problem!"

Regards kh



[gentoo-user] Preventing a package from being updated

2010-10-18 Thread Timur Aydin
Hi,

I am using the ~x86 (testing) version of gentoo linux. After recent
updates, my X windows became extremely sluggish and I found out that the
problem is related to a new version of mesa (7.8.2 specifically). So I
downgraded to version 7.7.1 and my desktop works great again.

Now I want to prevent mesa from being updated until this issue is sorted
out upstream. I have looked at package.provide, but that didn't work.
Currently, I have placed media-libs/mesa into my
/etc/portage/package.mask file and this seems to do the trick. Is this
the recommended way for handling this situation?

Being a long time gentoo user, I want to do things the right way, so
just working fine isn't enough :)

-- 
Timur