1 |
On Mon, 2002-01-28 at 09:54, Mirian Crzig Lennox wrote: |
2 |
|
3 |
> |
4 |
> When using portage, it's often the case that I know the name of the |
5 |
> package I want to install, but not what category it lives in. Under |
6 |
> debian, for example, I could say "apt-get install zsh" to install |
7 |
> zsh, whereas in gentoo, I seem to have to remember that zsh lives in |
8 |
> app-shells. This seems unnecessarily inconvenient, since it would |
9 |
> only be an issue if the same package name were used by more than one |
10 |
> package in more than one group. |
11 |
pkgsearch <foo> |
12 |
will return <category>/<foo> for you. |
13 |
It is found in /usr/lib/portage/bin |
14 |
|
15 |
> Another thing I kind of miss from other package systems is the |
16 |
> ability to know *before* I download a package what files it will |
17 |
> install. The Mandrake, Debian, and FreeBSD ports collection provide |
18 |
> this information in various forms, which I've gotten used to, but |
19 |
> the /usr/portage hierarchy doesn't seem to store it anywhere. |
20 |
knowing before hand would be a little tough, because what is installed |
21 |
can be dependent on *your* personal USE settings. After install you can |
22 |
find this info in /var/db/pkg/<category>/<foo>/CONTENTS |
23 |
|
24 |
> There are a few utilities which seem to be lacking, but which it |
25 |
> would appear to be trivial to add. Something like RPM's "rpm -qf |
26 |
> <file>" facility to find out which package "owns" a particular file |
27 |
> would be useful. This information is in the /var/db/pkg hierarchy, |
28 |
> so some kind of 'find&grep' method is all that's needed. |
29 |
|
30 |
Like the other replies have said, emerge app-admin/gentoolkit |
31 |
will give you several convenient scripts including qpkg, epm, and |
32 |
etc-update. |
33 |
|
34 |
> I've noticed that much of the "guts" of portage is written in |
35 |
> Python, which is a language I deeply respect and which certainly |
36 |
> makes sense for this kind of application, but which is not my |
37 |
> personal preference as a scripting language. However, it looks as |
38 |
> though all the Python code is confined to /usr/lib/portage; none of |
39 |
> the actual .ebuild scripts use Python. Is this a deliberate choice, |
40 |
> and if so, does this leave the door open for people wishing to |
41 |
> access portage from other languages, such as Ruby or Scheme? |
42 |
|
43 |
Unless, you want to hack the guts of portage, python coding isn't |
44 |
necessary. Ebuilds are bash with the addition of convenient bash helper |
45 |
scripts found in /usr/lib/portage/bin and are designed to be not very |
46 |
different from a typical ./configure, make, make install sequence for a |
47 |
manual installation from source. |
48 |
> |
49 |
> Finally, given that Gentoo is designed to be compiled from source at |
50 |
> install means that it should be fairly portable to other |
51 |
> architectures. Has anyone tried installing Gentoo on a non-i386 |
52 |
> architecture? I wouldn't mind giving it a shot on my PPC-based |
53 |
> iBook (currently running YellowDog 2.1). |
54 |
|
55 |
There have been rumors of a successful port to ppc on #gentoo. |
56 |
Package patching was required, IIRC |
57 |
|
58 |
TheMadHatter where are you!?!??! |
59 |
|
60 |
tod |