package.keywords

[James]

Well, I just tried something that seems to work,
but has me confused or missing the routine reading
of new portage features.....


Anyway upon a routine update (using portage 2.2_rc33
and sets for kde4) I got a message:


All ebuilds that could satisfy ">=dev-python/sip-4.8.1" have been masked.
One of the following masked packages is required to complete your request:
- dev-python/sip-4.8.1 (masked by: ~amd64 keyword)


So I just added this line to package.keywords:

" >=dev-python/sip-4.8.1 "



and it got passed that problem.....


'man portage' does not show the use of the (><=) syntax
as an example for emerge....?


Obviously, I'm behind on my routine reading. Is this
a no-no? Where can I read more about what's going on
with the newest changes to emerge/portage/etc.....?


James

[Albert Hopkins]

Post by James
Well, I just tried something that seems to work,
but has me confused or missing the routine reading
of new portage features.....
Anyway upon a routine update (using portage 2.2_rc33
All ebuilds that could satisfy ">=dev-python/sip-4.8.1" have been masked.
- dev-python/sip-4.8.1 (masked by: ~amd64 keyword)
" >=dev-python/sip-4.8.1 "
and it got passed that problem.....
'man portage' does not show the use of the (><=) syntax
as an example for emerge....?

This is a package atom... which AFAIK has at least been part of portage
since I've been using Gentoo (6 years).

man 5 portage

[James]

Post by James
'man portage' does not show the use of the (><=) syntax
as an example for emerge....?

Sorry for my sloppiness.... I should have been more precise
(more coffee required).

It should have read:

'man portage' does not show the use of the (><=) syntax
within the package.keywords file ?

For package.keywords I do use these symbols:
* package is visible if it is stable on any architecture
~* package is visible if it is in testing on any architecture
** package is always visible (KEYWORDS are ignored completely)
(and the tilde ~ symbol).
but not <> or =


Where do I read more and find more of the latest example for
syntax with portage and the different files therein?


???



James

[Arttu V.]

Post by James
Where do I read more and find more of the latest example for
syntax with portage and the different files therein?

<snip />

Post by James
'man portage' does not show the use of the (><=) syntax
within the package.keywords file ?

No, but it instructs one to peek into man 5 ebuild for the info. If
you look again at the portage manpage, the section on package.keywords
states of the file format:

"one DEPEND atom per line followed by additional KEYWORDS"

And at the top (Glossary) it says about these atoms:

"DEPEND atom
A string which matches a package. It is of the
form category/package. It may also contain optional logical operators
and versions.
More reading: ebuild(5)"

Follow this "more reading"-hint by entering "man 5 ebuild". The
resulting manpage tells you quite extensively (even everything?) about
the atoms, with many examples, and more.

It takes a meticulous, technically inclined (or otherwise
anal-retentive? :) ) mind to read these manpage-thingies which were
structured and invented before the modern hypertext-intarweb hit the
streets two decades ago. And sure, some of them are written badly, but
IMHO the gentoo ones are pretty ok from a user's POV.

So, as a conclusion, you probably want to use ~ instead of >= in there
as you apparently are running a mostly stable box (arch) instead of
testing (~arch)?

[James]

Post by Arttu V.
More reading: ebuild(5)"

Ah, ok so there is not restriction on using any of the
the boolean operators in any config file underneath
/etc/portage? as section 5 does not mention any....

Post by Arttu V.
So, as a conclusion, you probably want to use ~ instead of >= in there
as you apparently are running a mostly stable box (arch) instead of
testing (~arch)?

This is my (mis)conception, although, as you have suggest,
there are (gentoo) cultural norms that do suggest
certain boolean operations should not be used,
in say for example, package.keywords?


I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......



thanks,
James

[Alan McKinnon]

Post by Arttu V.
So, as a conclusion, you probably want to use ~ instead of >= in there

Post by Arttu V.
as you apparently are running a mostly stable box (arch) instead of
testing (~arch)?

This is my (mis)conception, although, as you have suggest,
there are (gentoo) cultural norms that do suggest
certain boolean operations should not be used,
in say for example, package.keywords?

That's more just a safeguard against forgetting you put it there than anything
else :-)

The vast majority of cases will use only the "=" operator or nothing. That's
so you unmask the one version you are interested in, not everything from here
on out, including every buggy, pre-release and just plain broken version that
happens to have an ebuild.

The use-case for no operator is mostly for the case where you run say a stable
box, and want the latest of a specific well-known package. You might want the
latest Qt for example. Another example is -svn ebuilds - enlightenment is a
case in point. The snapshots are always out of date, latest svn is pretty
stable, so one must unmask everything to get the -9999 versions

[James]

Post by Alan McKinnon

Post by James
This is my (mis)conception, although, as you have suggest,
there are (gentoo) cultural norms that do suggest
certain boolean operations should not be used,
in say for example, package.keywords?

That's more just a safeguard against forgetting you put it there than anything
else

Good to know.

Post by Alan McKinnon
The vast majority of cases will use only the "=" operator or nothing. That's
so you unmask the one version you are interested in, not everything from here
on out, including every buggy, pre-release and just plain broken version that
happens to have an ebuild.

So entries in package.keywords should just have the ~ in front of them?
No point in using other boolean operations in the package.keywords file?

Post by Alan McKinnon
The use-case for no operator is mostly for the case where you run say a stable
box, and want the latest of a specific well-known package. You might want the
latest Qt for example. Another example is -svn ebuilds - enlightenment is a
case in point. The snapshots are always out of date, latest svn is pretty
stable, so one must unmask everything to get the -9999 versions

Ok, now you just tossed my little (pee brain) around quite significantly...
Your saying that not operator will get me the -9999 (SVN) version
of a package?And that this is most likely the most stable because
the devs/hacks work on it often?


If so then lets put it to the test.
Maybee app-arch/xz-utils ?
so my entry in /etc/portage/package.keywords should look like this:

app-arch/xz-utils
Nothing I tried in either package.keywords or package.unmask
make the app-arch/xz-utils-9999 (SVN) version available.


So what did I miss?


James

[Nikos Chantziaras]

Post by James
[...]
So entries in package.keywords should just have the ~ in front of them?
No point in using other boolean operations in the package.keywords file?

There's a point to everything. You need to use whatever suits what you
want to do.

~: This version and all revision bumps of it.
=: This version.

Post by James
: Higher than this version.

<: Lower than this version.

Post by James
=: This and higher versions.

<=: This and lower versions.

Note that "revision bumps" are not higher versions. For example:

~some-category/foo-3.0.10

will match foo-3.0.10, foo-3.0.10-r1, foo-3.0.10-r2 and all "-rN"
versions of it, but will *not* match foo-3.0.11 nor 3.0.9. Just 3.0.10
and all revisions of it.

[James]

Post by Nikos Chantziaras
There's a point to everything. You need to use whatever suits what you
want to do.

<snip>

Ok got it.


Now how do I unmask the 9999 version of:

app-arch/xz-utils
Available versions: **9999


James

[Nikos Chantziaras]

Post by James

Post by Nikos Chantziaras
There's a point to everything. You need to use whatever suits what you
want to do.

<snip>
Ok got it.
app-arch/xz-utils
Available versions: **9999

By putting:

app-arch/xz-utils **

in package.keywords. I used that because 9999 is the only version
available. If you wish narrow it down nonetheless, use:

~app-arch/xz-utils-9999 **

[James]

Post by Nikos Chantziaras
app-arch/xz-utils **
in package.keywords. I used that because 9999 is the only version
~app-arch/xz-utils-9999 **

Both work!

got it now. Sorry but reading the man pages on portage and ebuild
did not clear this up, nor show a clear, precise example
as you have provided.

Should I file a bug under documentation? Or is this just
my weakness in comprehension?

It's also nice to have clarity on the boolean operations, with
details and examples provided.

thx,

James

[Alan McKinnon]

Post by James

Post by Nikos Chantziaras
app-arch/xz-utils **
in package.keywords. I used that because 9999 is the only version
~app-arch/xz-utils-9999 **

Both work!
got it now. Sorry but reading the man pages on portage and ebuild
did not clear this up, nor show a clear, precise example
as you have provided.
Should I file a bug under documentation? Or is this just
my weakness in comprehension?

Neither. A full understanding of portage and it's man pages is a recursive
process.

There is just no way you are going to get it all in your head the first time
round. Re-read them again and again, each time more sensible information
filters down into your awareness.

A process much like reading programming language documentation actually...

[Neil Bothwick]

Post by James
app-arch/xz-utils
Nothing I tried in either package.keywords or package.unmask
make the app-arch/xz-utils-9999 (SVN) version available.

This ebuild doesn't have a valid KEYWORDS line, try something less broken.

[James]

Post by Neil Bothwick

Post by James
make the app-arch/xz-utils-9999 (SVN) version available.

This ebuild doesn't have a valid KEYWORDS line, try something less broken.

OK, I tried is because there does not seem to be other dependancies.

Pick an example for me, cause nothing I ever do get me
a -9999 package variant for install on a stable system.

I understand what every one is has written, I just need
one example, not an exception like enlightenment....


OK?


James

[Alan McKinnon]

Post by James

Post by Alan McKinnon

Post by James
This is my (mis)conception, although, as you have suggest,
there are (gentoo) cultural norms that do suggest
certain boolean operations should not be used,
in say for example, package.keywords?

That's more just a safeguard against forgetting you put it there than
anything else

Good to know.

Post by Alan McKinnon
The vast majority of cases will use only the "=" operator or nothing.
That's so you unmask the one version you are interested in, not
everything from here on out, including every buggy, pre-release and just
plain broken version that happens to have an ebuild.

So entries in package.keywords should just have the ~ in front of them?
No point in using other boolean operations in the package.keywords file?

I personally have never used other operators. But Murphy says that as soon as
I say there's no need for them, someone will come along and prove me wrong :-)

It's not a bad thing to have all operators be valid syntax, then you (the
admin) can choose what you actually need

Post by James

Post by Alan McKinnon
The use-case for no operator is mostly for the case where you run say a
stable box, and want the latest of a specific well-known package. You
might want the latest Qt for example. Another example is -svn ebuilds -
enlightenment is a case in point. The snapshots are always out of date,
latest svn is pretty stable, so one must unmask everything to get the
-9999 versions

Ok, now you just tossed my little (pee brain) around quite significantly...
Your saying that not operator will get me the -9999 (SVN) version
of a package?And that this is most likely the most stable because
the devs/hacks work on it often?

I cheat and just do this:

x11-wm/enlightenment * ~* **

But enlightenment is a special case. e17 has never had a release (snapshots
that are known to build are not considered releases) and the majority of users
simply check out and build the latest commits in svn. The way the ebuilds are
versioned, enlightenment-9999 gets you the latest in svn.

That's a pretty normal gentoo convention

Post by James
If so then lets put it to the test.
Maybee app-arch/xz-utils ?
app-arch/xz-utils
Nothing I tried in either package.keywords or package.unmask
make the app-arch/xz-utils-9999 (SVN) version available.
So what did I miss?

You need to put a mask after the package name - *, ~* or **. The default is to
use your current ACCEPT_KEYWORDS.

* removes masking keywords if the package is stable on your arch
~* removes masking keywords if the package is stable on any arch
** removes masking keywords for the package unconditionally

[James]

Post by Alan McKinnon
x11-wm/enlightenment * ~* **

Does not work for xz-utils. Neil's post may be the reason,
but there is definately nothing I've read (in man pages)
to distinguish these anomalous cases....?

Post by Alan McKinnon
But enlightenment is a special case. e17 has never had a release (snapshots
that are known to build are not considered releases) and the majority of users
simply check out and build the latest commits in svn. The way the ebuilds are
versioned, enlightenment-9999 gets you the latest in svn.
That's a pretty normal gentoo convention
You need to put a mask after the package name - *, ~* or **. The default is to
use your current ACCEPT_KEYWORDS.
* removes masking keywords if the package is stable on your arch
~* removes masking keywords if the package is stable on any arch
** removes masking keywords for the package unconditionally

none of these worked for the
xz-utils package. Can we find a simple example that does work?
(not enlightenment).....?


James

[Alan McKinnon]

Post by James

Post by Alan McKinnon
* removes masking keywords if the package is stable on your arch
~* removes masking keywords if the package is stable on any arch
** removes masking keywords for the package unconditionally

none of these worked for the
xz-utils package. Can we find a simple example that does work?
(not enlightenment).....?

You want "app-arch/xz-utils **" in package.keywords. It is blocked by lzma,
but that entry does at least get the emerge past the mask stage:

nazgul xz-utils # echo "app-arch/xz-utils ~*" >
/etc/portage/package.keywords/temp
nazgul xz-utils # emerge -av1 xz-utils

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

Calculating dependencies... done!

!!! All ebuilds that could satisfy "app-arch/xz-utils" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-arch/xz-utils-9999 (masked by: missing keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

nazgul xz-utils # echo "app-arch/xz-utils **" >
/etc/portage/package.keywords/temp
nazgul xz-utils # emerge -av1 xz-utils

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

Calculating dependencies... done!
[ebuild N ] app-arch/xz-utils-9999 0 kB
[blocks B ] app-arch/lzma-utils ("app-arch/lzma-utils" is blocking app-
arch/xz-utils-9999)

[Neil Bothwick]

Post by James
I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......

It's easier to manage if you make portage.keywords a directory then put
the actual packages in files within that directory. That way you can
separate the files needed to run KDE4 from any other group of packages.

All package.* files in /etc/portage can be replaced a directories, then
all the files in that directory are considered as a whole.

[Dale]

Post by Neil Bothwick

Post by James
I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......

It's easier to manage if you make portage.keywords a directory then put
the actual packages in files within that directory. That way you can
separate the files needed to run KDE4 from any other group of packages.
All package.* files in /etc/portage can be replaced a directories, then
all the files in that directory are considered as a whole.

For some reason, my light bulb has still not came on so here comes some
questions. I would create /etc/portage/package.keywords then inside
that another directory or a set of files? Say, one named KDE4 to put
all of KDE4 and it's little friends and then another for some other set
of packages? Is this sort of like the sets thing which I am still
curious about?

Right now, package.keywords and friends are files not directories.
Maybe tarring up your portage directory and emailing me off list would
help? I need a light bulb moment here. :/

Dale

:-) :-)

[Neil Bothwick]

Post by Dale

Post by Neil Bothwick
All package.* files in /etc/portage can be replaced a directories,
then all the files in that directory are considered as a whole.

For some reason, my light bulb has still not came on so here comes some
questions. I would create /etc/portage/package.keywords then inside
that another directory or a set of files?

A set of files.

Post by Dale
Say, one named KDE4 to put
all of KDE4 and it's little friends and then another for some other set
of packages?

Exactly. The portage man page explains it well.

/etc/portage/
Any file in this directory that begins with "package." can be more than
just a flat file. If it is a directory, then all the files in that
directory will be sorted in ascending alphabetical order by file name
and summed together as if it were a single file.

Example:
/etc/portage/package.keywords/common
/etc/portage/package.keywords/e17
/etc/portage/package.keywords/kde

Post by Dale
Is this sort of like the sets thing which I am still
curious about?

Not really, it's just an alternative way of organising the package.* data.

[Alan McKinnon]

Post by Dale

Post by Neil Bothwick

Post by James
I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......

It's easier to manage if you make portage.keywords a directory then put
the actual packages in files within that directory. That way you can
separate the files needed to run KDE4 from any other group of packages.
All package.* files in /etc/portage can be replaced a directories, then
all the files in that directory are considered as a whole.

For some reason, my light bulb has still not came on so here comes some
questions. I would create /etc/portage/package.keywords then inside
that another directory or a set of files? Say, one named KDE4 to put
all of KDE4 and it's little friends and then another for some other set
of packages? Is this sort of like the sets thing which I am still
curious about?

Yes, precisely.

If package.keywords is a single file, then all your keywords must be in that
file. This is difficult for ebuilds to manipulate, and difficult for you to
edit too. If I send you my list of KDE keywords, you have to copy paste the
lot into a file and put comments at the start and end so you know what it all
is.

If package.keywords is a directory, then portage/ebuilds/tools/you can add and
remove entire files easily, leaving everything else untouched.

Post by Dale
Right now, package.keywords and friends are files not directories.
Maybe tarring up your portage directory and emailing me off list would
help? I need a light bulb moment here. :/

It's easy. As root:

cd /etc/portage
mv package.keywords package.keywords~
mkdir package.keywords
mv package.keywords~ package.keywords/package.keywords

The destination file in the last command can be named anything you like.

Now, if you install enlightenment, create and edit
/etc/portage/package.keywords/e17
If I send you my KDE keywords as an attachment, right-click, Save As,
/etc/portage/package.keywords/kde4

Done, sorted.

[Dale]

Post by Alan McKinnon

Post by Dale

Post by Neil Bothwick

Post by James
I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......

It's easier to manage if you make portage.keywords a directory then put
the actual packages in files within that directory. That way you can
separate the files needed to run KDE4 from any other group of packages.
All package.* files in /etc/portage can be replaced a directories, then
all the files in that directory are considered as a whole.

For some reason, my light bulb has still not came on so here comes some
questions. I would create /etc/portage/package.keywords then inside
that another directory or a set of files? Say, one named KDE4 to put
all of KDE4 and it's little friends and then another for some other set
of packages? Is this sort of like the sets thing which I am still
curious about?

Yes, precisely.
If package.keywords is a single file, then all your keywords must be in that
file. This is difficult for ebuilds to manipulate, and difficult for you to
edit too. If I send you my list of KDE keywords, you have to copy paste the
lot into a file and put comments at the start and end so you know what it all
is.
If package.keywords is a directory, then portage/ebuilds/tools/you can add and
remove entire files easily, leaving everything else untouched.

Post by Dale
Right now, package.keywords and friends are files not directories.
Maybe tarring up your portage directory and emailing me off list would
help? I need a light bulb moment here. :/

cd /etc/portage
mv package.keywords package.keywords~
mkdir package.keywords
mv package.keywords~ package.keywords/package.keywords
The destination file in the last command can be named anything you like.
Now, if you install enlightenment, create and edit
/etc/portage/package.keywords/e17
If I send you my KDE keywords as an attachment, right-click, Save As,
/etc/portage/package.keywords/kde4
Done, sorted.

This sounds cool. I don't unmask a lot or anything but something like
KDE 4 comes to mind for this. That requires a lot of work. I'm going
to have to check to see if autounmask supports this too.

Thanks much. Light bulb is glowing a bit now. o_O

Dale

:-) :-)

[Neil Bothwick]

Post by Dale
This sounds cool. I don't unmask a lot or anything but something like
KDE 4 comes to mind for this. That requires a lot of work. I'm going
to have to check to see if autounmask supports this too.

It does, it creates a file called autounmask-something, so it is obvious
where it came from and what it unmasks.

[Dale]

Post by Neil Bothwick

Post by Dale
This sounds cool. I don't unmask a lot or anything but something like
KDE 4 comes to mind for this. That requires a lot of work. I'm going
to have to check to see if autounmask supports this too.

It does, it creates a file called autounmask-something, so it is obvious
where it came from and what it unmasks.

It's been a while since I used it but I thought I saw a update being
done a while back.

May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the
login screen.

Dale

:-) :-)

[Alan McKinnon]

Post by Dale

Post by Neil Bothwick

Post by Dale
This sounds cool. I don't unmask a lot or anything but something like
KDE 4 comes to mind for this. That requires a lot of work. I'm going
to have to check to see if autounmask supports this too.

It does, it creates a file called autounmask-something, so it is obvious
where it came from and what it unmasks.

It's been a while since I used it but I thought I saw a update being
done a while back.
May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the
login screen.

Well that's easy, just don't use kdm :-)

If you want pretty, there's entrance
If you want light, there's slim
If you want hard-core, there's xdm

There's also gdm. But I don't talk about gdm. It's personal, and painful.
Don't ask :-)

[Weitao Sun]

Post by Alan McKinnon
There's also gdm. But I don't talk about gdm. It's personal, and painful.
Don't ask :-)

Well, tell us why you don't like gdm. :-)

;-p



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4180 (20090623) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Dale]

Post by Alan McKinnon

Post by Dale

Post by Neil Bothwick

Post by Dale
This sounds cool. I don't unmask a lot or anything but something like
KDE 4 comes to mind for this. That requires a lot of work. I'm going
to have to check to see if autounmask supports this too.

It does, it creates a file called autounmask-something, so it is obvious
where it came from and what it unmasks.

It's been a while since I used it but I thought I saw a update being
done a while back.
May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the
login screen.

Well that's easy, just don't use kdm :-)
If you want pretty, there's entrance
If you want light, there's slim
If you want hard-core, there's xdm
There's also gdm. But I don't talk about gdm. It's personal, and painful.
Don't ask :-)

Well, what I don't like is the clock with no seconds. I have a changing
background and I sort of like it to change on the 00's. I know exactly
how long it takes for me to type in my password, hit return and it start
the desktop. It's 11 seconds here. So, if I hit return right on 49
seconds, the background changes on the 00's every time.

The new KDE login doesn't have a second hand so I have no idea when to
hit the return key to login. I hate to say this, I may stick with KDE 3
until that is changed. There has to be a setting somewhere but this
little idiot can't find it.

I have never seen gdm so I'll take your word for it. I hate that little
startx thing. That is ugly. O-o

Dale

:-) :-)

[Neil Bothwick]

Post by Alan McKinnon
Well that's easy, just don't use kdm :-)
If you want pretty, there's entrance
If you want light, there's slim
If you want hard-core, there's xdm

If you want lazy, use kdm with auto-login.

[Arttu V.]

Post by James

Post by Arttu V.
More reading: ebuild(5)"

Ah, ok so there is not restriction on using any of the
the boolean operators in any config file underneath
/etc/portage? as section 5 does not mention any....

Well, for those files that are actually supposed to contain DEPEND
atoms that is probably true. I haven't checked the whole man page and
all files it lists to see if it places any restrictions on some
specific files therein, so I'm a bit timid to claim full "no limits"
either. But for package.keywords it didn't mention any limits and I'd
believe the others don't have them either. :)

Still, the best identifier of the allowed syntax is probably portage
itself. Make a typo in files under /etc/portage and portage will tell
you next time you emerge -pv something or emerge -av something.

And it also breaks in a quite predictable fashion when it reads your
typos in those files: it will just drop the lines it doesn't
understand (while also printing warning messages) and then dutifully
proceed to next line. So if ever in doubt, you can try it and see what
portage's parser thinks about your "fuzz-test". :)

Post by James
This is my (mis)conception, although, as you have suggest,
there are (gentoo) cultural norms that do suggest
certain boolean operations should not be used,
in say for example, package.keywords?

Not sure if by cultural norms you're referring to something I'd rather
label as "best practices"? :)

But then again, there are best practices for bleeding edge folks and
best practices for "stability is paramount" folks and they may
overlap, but most likely they aren't quite the same.

Post by James
I'm mostly running stable with exceptions being enabled
via the /etc/portage file structure. Usually it's small,
but now with kde4, BLOAT is my modus operandi,
not by choice......

Then, again, you probably don't want the >= as it will unmask the
latest testing version currently available, plus in future any new
testing grade versions as they get added to portage tree. What you
want is either = or ~. (And do note that ~ at the front of a DEPEND
atom means a different thing from the testing keyword in ~arch).

But it is all up to you to decide, you're the commander'n'chief of
your own boxen.