SEO

Is there a list somewhere of what is available to 'emerge'?? I looked
around the gentoo site but could not find anything. I'd like to see that
first before I go out and get sources for tons of stuff (like
'lmsensors').

thanks

http://packages.gentoo.org/

ray wrote:
> Is there a list somewhere of what is available to 'emerge'?? I looked
> around the gentoo site but could not find anything. I'd like to see that
> first before I go out and get sources for tons of stuff (like
> 'lmsensors').
>
> thanks
>

On Fri, 22 Oct 2004 00:18:55 +0200, Albert wrote:

> http://packages.gentoo.org/
>
> ray wrote:
>> Is there a list somewhere of what is available to 'emerge'?? I looked
>> around the gentoo site but could not find anything. I'd like to see that
>> first before I go out and get sources for tons of stuff (like
>> 'lmsensors').
>>
>> thanks
>>

Thanks - that's what I was looking for. Now that's what I call response
time!!

I'm playing with gentoo on my mini-itx system. So far, quite pleased -
I've been running other linux distros for a couple of years.

ray wrote:

> Is there a list somewhere of what is available to 'emerge'?? I looked
> around the gentoo site but could not find anything. I'd like to see that
> first before I go out and get sources for tons of stuff (like
> 'lmsensors').
>
> thanks

For offline use:
ACCEPT_KEYWORDS="~x86" emerge porthole

Thomas

My pleasure.
I started with Mandrake 8.0 a long time ago, just for fun, and then for
my daily use with Mandrake 9.2.
After some time I looked too often under the hood and broke it. Very
frustrating experience.
Gentoo is very good. No plan to move to another one. It is not a distro
in the sense you don't need to wait for bundled releases.
The good surprise is that I've never seen any breakdown, just trouble
when upgrading to the 2.6.8 kernel, with sound and video drivers. Now
it's allright.
I think .org distros are going to take a lot of importance.

ray wrote:
> On Fri, 22 Oct 2004 00:18:55 +0200, Albert wrote:
>
>
>>http://packages.gentoo.org/
>>
>>ray wrote:
>>
>>>Is there a list somewhere of what is available to 'emerge'?? I looked
>>>around the gentoo site but could not find anything. I'd like to see that
>>>first before I go out and get sources for tons of stuff (like
>>>'lmsensors').
>>>
>>>thanks
>>>
>
>
> Thanks - that's what I was looking for. Now that's what I call response
> time!!
>
> I'm playing with gentoo on my mini-itx system. So far, quite pleased -
> I've been running other linux distros for a couple of years.
>
>

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

Thomas Krüger wrote:

> ACCEPT_KEYWORDS="~x86" emerge porthole

Nonono ... Do not *ever* emerge anything with temporary environment
variables on the command line! It breaks the way portage works in
subtle but important ways! Instead set the keyword for the package in
/etc/portage/package.keywords. Read 'man portage' for more information.

For the OP, you may want to install app-portage/esearch. It's
incredibly fast at searching the portage database.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBeKJLd1ZThqotgfgRAk2YAKCnf9MbK9F7X9jkArSKKq tnDxVXfACgsEUc
Xh1ZITo9XBV1XPJjWdnXsvU=
=6qGT
-----END PGP SIGNATURE-----
--
PeKaJe

Be it our wealth, our jobs, or even our homes; nothing is safe while the
legislature is in session.

On Fri, 22 Oct 2004 06:01:50 +0000, Peter Jensen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Krüger wrote:
>
>> ACCEPT_KEYWORDS="~x86" emerge porthole
>
> Nonono ... Do not *ever* emerge anything with temporary environment
> variables on the command line! It breaks the way portage works in
> subtle but important ways! Instead set the keyword for the package in
> /etc/portage/package.keywords. Read 'man portage' for more information.
>
> For the OP, you may want to install app-portage/esearch. It's
> incredibly fast at searching the portage database.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFBeKJLd1ZThqotgfgRAk2YAKCnf9MbK9F7X9jkArSKKq tnDxVXfACgsEUc
> Xh1ZITo9XBV1XPJjWdnXsvU=
> =6qGT
> -----END PGP SIGNATURE-----

Thanks, I'll keep that in mind. Right now, I'm interested in just browsing
the lists.

Peter Jensen wrote:
[...]
>> ACCEPT_KEYWORDS="~x86" emerge porthole
>
> Nonono ... Do not *ever* emerge anything with temporary environment
> variables on the command line! It breaks the way portage works in
> subtle but important ways!

Which ways are those, please?

Would it be fine to use those variables for an "emerge -f" of something?

Sometimes I use "emerge" to fetch something, then compile it "manually".

R.

Rolleston wrote:

>>> ACCEPT_KEYWORDS="~x86" emerge porthole
>>
>> Nonono ... Do not *ever* emerge anything with temporary environment
>> variables on the command line! It breaks the way portage works in
>> subtle but important ways!
>
> Which ways are those, please?

Well, for one it will break the way portage calculates updates, and you
may end up with fun stuff like cyclic upgrades/downgrades. Most likely,
however, is that the next system-wide upgrade will downgrade the package
(unless all are masked). This can of course be prevented with -U
instead of -u, but that's not only deprecated, it's also quite dangerous
to use.

Another thing is that if your system is relatively new or you have never
compiled a large package with many dependencies, you will run into
problems because all the dependencies are affected by the command line
ACCEPT_KEYWORDS as well. I once nearly killed my system when doing this
trick with KDevelop.

> Would it be fine to use those variables for an "emerge -f" of
> something?

Oh, no problem at all. Anything short of an actual merge is safe. I
still use the trick from time to time when doing a quick emerge -p. It
saves me a bit of time when doing the research before editing the
package.keywords file.

> Sometimes I use "emerge" to fetch something, then compile it
> "manually".

One word: Ick. I have yet to see anyone provide a good reason why an
ebuild should not be used when present. On a typical Gentoo system,
/usr/local/ should be all but empty. If not, you may be endangering the
way portage works. Just be careful if you plan to keep doing that ...

--
PeKaJe

Vegetarians beware! You are what you eat.

Peter Jensen wrote:
> Rolleston wrote:
>>> Nonono ... Do not *ever* emerge anything with temporary environment
>>> variables on the command line! It breaks the way portage works in
>>> subtle but important ways!
>>
>> Which ways are those, please?
>
> Well, for one it will break the way portage calculates updates, and you
> may end up with fun stuff like cyclic upgrades/downgrades. Most likely,
> however, is that the next system-wide upgrade will downgrade the package
> (unless all are masked). This can of course be prevented with -U
> instead of -u, but that's not only deprecated, it's also quite dangerous
> to use.
>
> Another thing is that if your system is relatively new or you have never
> compiled a large package with many dependencies, you will run into
> problems because all the dependencies are affected by the command line
> ACCEPT_KEYWORDS as well. I once nearly killed my system when doing this
> trick with KDevelop.

Thanks.

>> Would it be fine to use those variables for an "emerge -f" of
>> something?
>
> Oh, no problem at all. Anything short of an actual merge is safe. I
> still use the trick from time to time when doing a quick emerge -p. It
> saves me a bit of time when doing the research before editing the
> package.keywords file.
>
>> Sometimes I use "emerge" to fetch something, then compile it
>> "manually".
>
> One word: Ick. I have yet to see anyone provide a good reason why an
> ebuild should not be used when present.

Suppose you want to install packages under a non-root user account,
and want all the libraries placed under "$HOME/lib", etc? I can't
see a way to do that with "emerge".

Thanks,

R.