SEO

Martin Vaeth wrote:
> J.O. Aho <user@example.net> wrote:
>> echo "=sys-devel/gcc-4.3.0 -* ~*" >> /etc/portage/package.keywords
>
> -* is obsolete, and using "=" is problematic since you wont get upgrades
> (which might be security relevant).
>
>> emerge =sys-devel/gcc-4.3.0
>
> The best way to unmask things is to use first "eix" or even "eix -l"
> for the package:
> It will show you whether ~ARCH (=nothing) is sufficient or whether you
> need * (or to specify the alien architecture directly) or ~* (or to
> specify the alien testing architecture directly) or even ** (to unmask
> regardless of anything).
> You should not use a stronger keywords than necessary to avoid undesired
> upgrades. eix -T (or eix-test-obsolete) will "warn" you if you used too
> much...

According to eix, glibc-2.7-r2 is "~amd64". Putting just
"sys-libs/glibc" in package.keywords (without ~* or **) unmasks it
correctly. So that means every future glibc will be unmasked if it's
~amd64? (The same effect as putting "~amd64" in ACCEPT_KEYWORDS, but
only for glibc?)

`eix -l gcc` says that 4.3.0 is "**". So I guess ">=sys-libs/gcc-4.3.0
**" is the correct way to unmask until GCC 4.3 enters ~amd64?

Nikos Chantziaras <realnc@arcor.de> wrote:
>
> Putting just
> "sys-libs/glibc" in package.keywords (without ~* or **) unmasks it
> correctly. So that means every future glibc will be unmasked if it's
> ~amd64? (The same effect as putting "~amd64" in ACCEPT_KEYWORDS, but
> only for glibc?)

Exactly (supposed your ARCH is amd64). This is usually what you want,
because security issues are usually not fixed (and sometimes not even
reported) for ~ARCH versions, i.e. *if* you run an ~ARCH version, better
use the highest one.

> `eix -l gcc` says that 4.3.0 is "**". So I guess ">=sys-libs/gcc-4.3.0
> **" is the correct way to unmask until GCC 4.3 enters ~amd64?

Yes. And when this happens, you should remove the "**" unless you want
to continue to install the newest bleeding edge gcc. (This is why
eix-test-obsolete informs about it - of course, only if you run it
after eix-sync and *before* emerge -NDu world).

Nikos Chantziaras wrote:

> According to eix, glibc-2.7-r2 is "~amd64". Putting just
> "sys-libs/glibc" in package.keywords (without ~* or **) unmasks it
> correctly. So that means every future glibc will be unmasked if it's
> ~amd64? (The same effect as putting "~amd64" in ACCEPT_KEYWORDS, but
> only for glibc?)

#Always use unstable version if there is one
sys-libs/glibc ~amd64

#Use unstable 2.7-r2 until a later version gets stable
=sys-libs/glibc-2.7-r2 ~amd64

Much depends on how you want to have things, but you should avoid using

ACCEPT_KEYWORDS=~amd64 emerge something

This will cause problems for you when you have to do something like
revdep-rebuild, as the system can't build the packages, and the same if you
use --deep when you emerge.

If you want to use unstable, then better switch to unstable, see make.conf.example


--

//Aho

J.O. Aho wrote:
> Nikos Chantziaras wrote:
>
>> According to eix, glibc-2.7-r2 is "~amd64". Putting just
>> "sys-libs/glibc" in package.keywords (without ~* or **) unmasks it
>> correctly. So that means every future glibc will be unmasked if it's
>> ~amd64? (The same effect as putting "~amd64" in ACCEPT_KEYWORDS, but
>> only for glibc?)
>
> #Always use unstable version if there is one
> sys-libs/glibc ~amd64

What exactly happens if I omit "~amd64"? (As I'm doing right now; I
have just "sys-libs/glibc".)


> Much depends on how you want to have things, but you should avoid using
>
> ACCEPT_KEYWORDS=~amd64 emerge something

I'm not doing that; I've read the heads-up warnings on gentoo-wiki.

One thing about ACCEPT_KEYWORDS though: should it be empty in make.conf?
I would have imagined that actually the default should have been
ACCEPT_KEYWORDS="amd64" :S


> If you want to use unstable, then better switch to unstable, see
> make.conf.example

Well, problem is that I don't know if I want to use unstable. Right
now, I want to use stable but with one experimental package (GCC 4.3.0).

Nikos Chantziaras <realnc@arcor.de> wrote:
> J.O. Aho wrote:
>>
>> #Always use unstable version if there is one
>> sys-libs/glibc ~amd64
>
> What exactly happens if I omit "~amd64"?

Nothing, this is equivalent: An empty entry is a shortcut for ~ARCH.

> One thing about ACCEPT_KEYWORDS though: should it be empty in make.conf?
> I would have imagined that actually the default should have been
> ACCEPT_KEYWORDS="amd64" :S

Also here, it doesn't matter: The default is ACCEPT_KEYWORDS="$ARCH"
and everything which you add in make.conf is just added
(with the exception of "-*" which - in the new syntax - clears everything
which was in this string before).

>> If you want to use unstable, then better switch to unstable, see
>> make.conf.example
>
> Well, problem is that I don't know if I want to use unstable.

Probably, there is not *so* much difference in the stability which
you will actually observe. However, the main difference is the number
of packages which you will have to recompile: There are much more often
new ~ARCH versions than new ARCH versions (especially for amd64).
And stepping back can be difficult. For example, downgrading glibc usually
breaks your system (current ebuilds even won't allow it at all).

Nikos Chantziaras wrote:

>> #Always use unstable version if there is one
>> sys-libs/glibc ~amd64
>
> What exactly happens if I omit "~amd64"? (As I'm doing right now; I
> have just "sys-libs/glibc".)

Man portage says that "lines without any KEYWORDS imply unstable host arch".
However, I always prefer to explicitly specify the arch keyword (eg,
~amd64).

> One thing about ACCEPT_KEYWORDS though: should it be empty in make.conf?
> I would have imagined that actually the default should have been
> ACCEPT_KEYWORDS="amd64" :S

It should be either unset or nonempty (I don't know what happens it you
explicitly set it to the empty string; might work and assume stable, but
I'm not sure).
Take a look at /etc/make.conf.example (don't know if you have it; with
normal text-mode install it's there). Basically, each value that is not
explicitly set in make.conf has a default value. The file make.conf.example
does a good job at showing what these defaults are (I usually take that
file as a starting point for a new install, instead of the almost empty
make.conf provided).
A way to see your current configuration (and thus see defaults for values
you have not set) is to run "emerge --info" or to use the portageq tool
(portageq --help for help)

> Well, problem is that I don't know if I want to use unstable. Right
> now, I want to use stable but with one experimental package (GCC 4.3.0).

If you want to use unstable, just be prepared to upgrade packages frequently
and encounter some occasional breakage. And, of course, with an unstable
system it's almost mandatory to run emerge --sync and emerge world quite
often.