Talk:HOWTO Use Portage Correctly
From Gentoo Linux Wiki
See http://forums.gentoo.org/viewtopic.php?t=188003&highlight= for a discussion on making ~ARCH the default keyword.
Contents |
[edit] Headline?
I'd like to put this on the front page of gentoo-wiki, but before that happens it's gonna need a good introduction and closing. If anyone feels up to it, you're free to add it in! -- MighMoS 23:48, 3 Apr 2005 (GMT)
regarding the "emerge --tree (-t)" option it says "Display the dependency tree for the package/target. This is an insanely useful option that no one ever uses. If you've ever tried to figure out what's pulling in a particular package, or just wanted to see what depends on what, this is the option for you" and it goes on to show how to display the dependencies of a package.. but how to do the other mentioned thing, "what's pulling in a particular package" ?
[edit] Missing Keywords
The suggestions on missing keywords don't work! Try that with openoffice on amd64 or sparc!
[edit] masked by: missing keyword
Unmasking packages without keywords (e.g. those from overlays like beryl-settings-bindings-9999) can be achieved by adding it to /etc/portage/package.keywords with the "-*" mark after the package name.
Note: IT IS NOT A TILDE (~), IT'S A DASH (-)!!! This is an error on the article page. Should be fixed!
Example:
=x11-misc/beryl-settings-bindings-9999 -*
--loony
Actually, after trying this myself, it seems that neither of those are correct... according to the portage manpage:
* 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)
The only way I was unable to get a package with missing keywords emerged (in my case media-sound/ardour2 from the pro-audio overlay) was to use "**". --whitelynx
[edit] Versions in keywords = bad idea
I don't know about you, But I think permitting version specific keywords is a bad bad bad idea.
I thought the whole _point_ of the keyword rules were to govern what software gets let through as a stable version, and what doesnt?
Not to mention multiple ranges of keywords such as
>=sys-kernel/gentoo-sources-2.6.15 -x86 -~x86 >=sys-kernel/gentoo-sources-2.6.16 x86 -~x86
results in the latter being COMPELETLY and UTTERLY ignored, despite portage seeing it as valid code. While it may be usefull to unmask a singular version number with a specific keyword, to me it seems like a very big blind oversight, and something that should be governable by package.mask and package.unmask
But on the contrary, a package.use could _well_ do with version specific flags, especially as its not uncommon for there to exist parallel/slotted installs of things, which have their own different set of keywords
An anwser: I don't agree. I have things like:
=sys-power/kpowersave-0.6* ~amd64 ~app-office/koffice-meta-1.6.1 ~amd64 (etc...)
in my keywords file, because that way, I target a specific version (and its revisions) to be keyword unmasked, e.g because I need a specific feature. this allows me to upgrade to that one and wait for the next version to become stable before upgrading again, with minimal effort. and that way, I'm not caught in the 'forever testing race' where I would be constantly upgrading on each new testing release, and have to downgrade to be back into stable, and will only go willingly into testing with a minimal amount of packages. I call that approach "almost stable".
[edit] world file role
"First, a bit on what the world file actually is. The intention of the world file is to record the list of packages that the user wishes to have upgraded normally" This is wrong. The intent of the world file is to know which packages are purposedly installed, and are not pulled in as dependencies. Stating this kind of things is why people can't use --depclean (and later on, revdep-rebuild) properly and complain as to why it resolves things badly and misses stuff. World file dos NOT contains things you want to update, but things you want to STAY (ie, be part of the world, hence the name). see man emerge, --depclean section, and disregard --oneshot section. A properly maintained world file allows for things like 'emerge -C kde-meta && emerge --depclean && revdep-rebuild' do what we expect them to do.
- Agreed. I've rewritten this section of the article. --AllenJB 16:42, 23 January 2007 (UTC)
[edit] MergeTo Nomination
I've nominated this page to be merged to HOWTO Maintain Gentoo - "Best Practices" because that article is far more thorough, accurate and up-to-date. --AllenJB 16:45, 23 January 2007 (UTC)
[edit] Colored Output
Will someone who knows, please indicate why certain USE flags are colored blue. I added the section, but I have no idea what the blue stands for. --Penguin of Wonder 05:05, 30 January 2007 (UTC)
The article now reads "Any USE flag within parenthesis will be colored blue and this indicates that the USE flag is currently masked by your profile. ...", but afaik that's not the case. Red indicates that the use-flag used for this package, and blue says the opposite - the use-flag is not enabled for this package. Flags in parenthesis are masked by the profile, like the text says. I looked at the history, and the original entry was talking about use-flags in parenthesis being blue, and the next modification added the explanation of the parenthesis - some later modification has tried to tidy up the text altering the truth in the process. Blue = flag not on, parenthesis = masked. I added this to the article, but felt like i should clear this up here, so someone other doesn't think *this* was a tidy-up which modified the right thing :) --Alexer 01:26, 13 April 2007 (UTC)
On my screen, package names are either light green or dark green when using emerge. I suspect that the light ones are packages in my world file, whereas dark ones are pulled in as dependencies. Can anyone confirm this and add this information to the page? --sluys 03:06, 14 February 2008 (UTC)
[edit] [nomerge]
I was looking for info on what [nomerge] meant when using the --tree (-t) option. While it was fairly obvious in hindsight, it should nevertheless be included in this article. Packages marked with [nomerge] are used to show packages which are not going to be emerged, but has a dependency who needs to be emerged. --62.16.191.231 10:55, 23 November 2007 (UTC)
