SEO

Hello,

lets assume, the package foo/bar-0.42 is masked by ~keyword. I've
learned that I can put a line into /etc/portage/package.keywords to
emerge it:

=foo/bar-0.42

Then I test the package and I'm lucky with it. I'm *not* interested in
future versions >0.42, if they are also masked, because I don't want
to repeat the tests. But I'm very interested in future versions >0.42,
which are *not* masked at all.

Can I achieve that in an easy, automatical way?

Regards
Thomas

--
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)

Thomas Hafner enlightened us with:
> I can put a line into /etc/portage/package.keywords to emerge it:
>
>=foo/bar-0.42
>
> Then I test the package and I'm lucky with it. I'm *not* interested
> in future versions >0.42, if they are also masked, because I don't
> want to repeat the tests. But I'm very interested in future versions
> >0.42, which are *not* masked at all.
>
> Can I achieve that in an easy, automatical way?

Yes. Stop worrying and let Portage do it's thing. It's already set up
like that ;-)

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sybren Stuvel wrote:
> Thomas Hafner enlightened us with:
>
>>I can put a line into /etc/portage/package.keywords to emerge it:
>>
>>=foo/bar-0.42
>>
>>Then I test the package and I'm lucky with it. I'm *not* interested
>>in future versions >0.42, if they are also masked, because I don't
>>want to repeat the tests. But I'm very interested in future versions
>>
>>>0.42, which are *not* masked at all.
>>
>>Can I achieve that in an easy, automatical way?
>
>
> Yes. Stop worrying and let Portage do it's thing. It's already set up
> like that ;-)
>
> Sybren

Hi,
There is one problem here. After a while, the masked 0.42 ebuild might
be replaced with, say 0.43, also masked. The next emerge sync will
delete the 0.42 and replace it with 0.43. Since you haven't unmasked
0.43, it can't upgrade. When you run emerge -uatvDN world, it will then
try to DOWNGRADE the package. 0.42 "doesn't exist" any more, so it'll
ask you to downgrade to, say, 0.38 (latest not-masked package). I
discovered this with PHP.

I'm not sure what the proper solution for this is. My solution involved
copying the PHP 5.0.3 ebuild and its associated files from the Portage
tree and putting them into my overlay. This keeps them available to
Portage, which then doesn't keep bugging me to downgrade. Once something
above 5.0.3 is available AND STABLE, Portage will happily upgrade, and I
can delete my overlay.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCwzkcgxSrXuMbw1YRAtK/AJ9ibEzdQB39khYoS+uQigUIReFiIQCgmpBC
G0EZf1fUpsFInnKdSMq4DPc=
=TD6M
-----END PGP SIGNATURE-----

Chris Head wrote:
> There is one problem here. After a while, the masked 0.42 ebuild might
> be replaced with, say 0.43, also masked.

Do you really mean "replaced", so that version 0.42 disappears from the
Portage tree entirely? That would be a nasty situation. Wouldn't it
only happen if version 0.42 was found to have a major flaw (probably
security), in which case it would be very wise to either upgrade or
downgrade anyway?


I initially thought that you meant that 0.42 and 0.43 co-existed, so I
was going to say that for "emerge" to choose 0.43 over 0.42,
package.keywords would need:
>=foo/bar-0.42
or
~foo/bar

Rather than:
=foo/bar-0.42

Chris Head enlightened us with:
> Since you haven't unmasked 0.43, it can't upgrade. When you run
> emerge -uatvDN world, it will then try to DOWNGRADE the package.
> 0.42 "doesn't exist" any more, so it'll ask you to downgrade to,
> say, 0.38 (latest not-masked package). I discovered this with PHP.

If they really delete a version, it's for a good reason. You shouldn't
use that version any more.

> I'm not sure what the proper solution for this is.

Upgrade to another masked version, or stick to the stable one.

> My solution involved copying the PHP 5.0.3 ebuild and its associated
> files from the Portage tree and putting them into my overlay.

That'll do what you want. I don't reccomend it, though.

> This keeps them available to Portage, which then doesn't keep
> bugging me to downgrade.

Again: there are always reasons for a move like that. I strongly
suggest you re-think your strategy.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sybren Stuvel wrote:
> Chris Head enlightened us with:
>
>>Since you haven't unmasked 0.43, it can't upgrade. When you run
>>emerge -uatvDN world, it will then try to DOWNGRADE the package.
>>0.42 "doesn't exist" any more, so it'll ask you to downgrade to,
>>say, 0.38 (latest not-masked package). I discovered this with PHP.
>
>
> If they really delete a version, it's for a good reason. You shouldn't
> use that version any more.
>
>
>>I'm not sure what the proper solution for this is.
>
>
> Upgrade to another masked version, or stick to the stable one.
>
>
>>My solution involved copying the PHP 5.0.3 ebuild and its associated
>>files from the Portage tree and putting them into my overlay.
>
>
> That'll do what you want. I don't reccomend it, though.
>
>
>>This keeps them available to Portage, which then doesn't keep
>>bugging me to downgrade.
>
>
> Again: there are always reasons for a move like that. I strongly
> suggest you re-think your strategy.
>
> Sybren

Hmm. Thanks Paul and Sybren; yes, I mean that the package ACTUALLY
DISAPPEARED from Portage! (I decided to do what I did [save it in my
overlay] because I was under the impression that this was a normal
thing; otherwise after ten releases of a package your Portage tree would
start to get very big). Unfortunately using a stable version is not an
option at this time (I'd like to go stable, but I can't stand PHP4...
anyone know when PHP5 is going stable?) Unfortunately this meant I had
to upgrade Apache, APR, APR-util, and Gentoo-webroot-default all to
unstable versions (I've just bitten the bullet and done it). I guess
once PHP5 becomes stable I'll slowly and gently start downgrading
packages until I become stable again.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCxBRfgxSrXuMbw1YRAqr1AKDvzwP7bbAusg1kYWdxbi oDG7RDUgCffiN/
Z1/ZqfsefgA/jHAo0bM+H9U=
=qF4d
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Head wrote:
> Sybren Stuvel wrote:
>
>>>Chris Head enlightened us with:
>>>
>>>
>>>>Since you haven't unmasked 0.43, it can't upgrade. When you run
>>>>emerge -uatvDN world, it will then try to DOWNGRADE the package.
>>>>0.42 "doesn't exist" any more, so it'll ask you to downgrade to,
>>>>say, 0.38 (latest not-masked package). I discovered this with PHP.
>>>
>>>
>>>If they really delete a version, it's for a good reason. You shouldn't
>>>use that version any more.
>>>
>>>
>>>
>>>>I'm not sure what the proper solution for this is.
>>>
>>>
>>>Upgrade to another masked version, or stick to the stable one.
>>>
>>>
>>>
>>>>My solution involved copying the PHP 5.0.3 ebuild and its associated
>>>>files from the Portage tree and putting them into my overlay.
>>>
>>>
>>>That'll do what you want. I don't reccomend it, though.
>>>
>>>
>>>
>>>>This keeps them available to Portage, which then doesn't keep
>>>>bugging me to downgrade.
>>>
>>>
>>>Again: there are always reasons for a move like that. I strongly
>>>suggest you re-think your strategy.
>>>
>>>Sybren
>
>
> Hmm. Thanks Paul and Sybren; yes, I mean that the package ACTUALLY
> DISAPPEARED from Portage! (I decided to do what I did [save it in my
> overlay] because I was under the impression that this was a normal
> thing; otherwise after ten releases of a package your Portage tree would
> start to get very big). Unfortunately using a stable version is not an
> option at this time (I'd like to go stable, but I can't stand PHP4...
> anyone know when PHP5 is going stable?) Unfortunately this meant I had
> to upgrade Apache, APR, APR-util, and Gentoo-webroot-default all to
> unstable versions (I've just bitten the bullet and done it). I guess
> once PHP5 becomes stable I'll slowly and gently start downgrading
> packages until I become stable again.
>
> Chris

Hi again,
The moment after I posted this message I actually tried to update world,
and discovered that this won't work. Apache 2.0.54-r10 blocks
Subversion, and I really don't want to go crazy with my source control
system. I guess it's back to PHP 5.0.3 until something becomes stable
again... I know it's not the recommended way, but I simply can't seem to
figure out how to do it right without making a giant cascade of unstable
packages. I'd rather have ONE bad package than ten unstable (since it's
only a development server anyway).

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCxBTzgxSrXuMbw1YRAjeXAJ4pIharHkj8/PiCUIHpV6KCZMxtAQCcCsYG
v9Ai2hs28AwEDZCfZPJm4B8=
=eGZi
-----END PGP SIGNATURE-----

Chris Head enlightened us with:
> Hmm. Thanks Paul and Sybren;

Please snip the unneeded quoted text from your post. Why do you want
people to scroll when it's not really needed?

> yes, I mean that the package ACTUALLY DISAPPEARED from Portage!

I know, it happens.

> (I'd like to go stable, but I can't stand PHP4...

I can imagine, because neither can I. I moved away from PHP
alltogether, and now I use mod_python to write dynamic pages. Python
is a far superior language to PHP, at least from my point of view.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa