| 1 |
Hello, |
| 2 |
|
| 3 |
I'm playing with portage and noticed it's well designed, but there are |
| 4 |
some mistakes in its usage at the moment. For example: |
| 5 |
|
| 6 |
Categories are mixed: there is a net-www/apache and net-www/mod_* |
| 7 |
(apache modules), but there is a more convenient category www-apache/ |
| 8 |
for them. This is one example, there are more mistakes. There is any |
| 9 |
plan to fix them in next portage releases? |
| 10 |
|
| 11 |
Some packages use numbering version padded with zero, that's good to |
| 12 |
list with shell functions, but it's bad because you can't change them |
| 13 |
to numbers and them back to string. For example: |
| 14 |
mail-mta/nullmailer-1.00_rc7-r4. If you Convert it to integers, it |
| 15 |
becomes 1.0 and you can't map back to the ebuild. |
| 16 |
|
| 17 |
Portage provides metadata.xml, cool. But it's hardly used :( |
| 18 |
metadata.xml seems to provide tags for maintainers, changelogs and |
| 19 |
long description, many (most?) packages don't use them. |
| 20 |
|
| 21 |
The portage library is too heavy, complicated and make things slow. |
| 22 |
Heavy and complicated I noticed from (trying to) look at the source, |
| 23 |
slow by usage. For example: |
| 24 |
|
| 25 |
time emerge # without parameters |
| 26 |
real 0m0.614s |
| 27 |
user 0m0.487s |
| 28 |
sys 0m0.046s |
| 29 |
|
| 30 |
time emerge -pv world # 16 packages to be upgraded |
| 31 |
real 0m22.664s |
| 32 |
user 0m12.423s |
| 33 |
sys 0m1.130s |
| 34 |
|
| 35 |
It's too much, look at debian apt, it's fast. And I can't see why |
| 36 |
portage is slow. |
| 37 |
Forgive me if I'm wrong, but portage just need to parse |
| 38 |
/var/lib/portage/world (237 entries in my case), them for each check |
| 39 |
if there is any other version greater than and if so check for |
| 40 |
dependencies. Why 22seconds? A hand made take less than 1. |
| 41 |
|
| 42 |
|
| 43 |
Also, a brief explanation on why I was playing with portage and some |
| 44 |
requests: I'm coding (for fun, no plan to get in a production state) |
| 45 |
yet another graphical package manager atop portage with the newbie in |
| 46 |
mind. But to achieve my goal I need: |
| 47 |
|
| 48 |
- a fast portage. Now I'm doing a module to do this for me (see |
| 49 |
more above), at least the basics, like get package information, |
| 50 |
versions, ... and if possible resolve primary dependencies (just to |
| 51 |
show to user in a tab "Dependencies", hidden by default). |
| 52 |
|
| 53 |
- more meta data, if possible a list of urls to screenshots (most |
| 54 |
packages have a screenshots section), if the url links to an html, |
| 55 |
provide a threshold of images size to get, so it connects and |
| 56 |
downloads every image bigger than it... cached of course. |
| 57 |
|
| 58 |
- portage to act as a daemon, queue requests and fetch packages. |
| 59 |
If portage could be a daemon with 3 threads: one that download |
| 60 |
packages, one that compiles and one to manage the other and accept |
| 61 |
requests; then it could schedule download to maximize download |
| 62 |
throughput, downloading smaller packages first while respecting |
| 63 |
dependencies, compile while download and wait until packages are there |
| 64 |
and the "emerge" command just send commands to it. It would be handy |
| 65 |
since compiling times are huge. |
| 66 |
|
| 67 |
|
| 68 |
About the fast portage: I know portage is a complex monster and is the |
| 69 |
heart of gentoo, if it breaks, everything breaks. But how about a |
| 70 |
python module to be used by other packages that just want to view the |
| 71 |
portage and its packages. If eventually this module works as expected |
| 72 |
and have every current portage feature, it could replace the old one. |
| 73 |
I started to code my own "fast portage", but some things are picky |
| 74 |
to do, and I want to know how you do that: how do you parse ebuilds to |
| 75 |
get USE, DESCRIPTION, SLOT, DEPEND, ... ? |
| 76 |
If you want to know why my implementation is fast: I use lazy |
| 77 |
evaluation as far as possible. For example, I load every package, but |
| 78 |
the attributes to available versions, installed versions, the status, |
| 79 |
are just calculated on deman, I use python property() and |
| 80 |
setters/getters for that. Since hardly you'll use every attribute from |
| 81 |
everythin, it loads much faster. |
| 82 |
I have preliminar code here: |
| 83 |
http://ltc08.ic.unicamp.br/~gustavo/packagemanager.tar.bz2, but some |
| 84 |
modifications I did were lost in a power outtage + xfs... I just have |
| 85 |
the .pyc, if someone knows how to get the .py back... |
| 86 |
|
| 87 |
|
| 88 |
-- |
| 89 |
Gustavo Sverzut Barbieri |
| 90 |
--------------------------------------- |
| 91 |
Computer Engineer 2001 - UNICAMP |
| 92 |
GPSL - Grupo Pro Software Livre |
| 93 |
Cell..: +55 (19) 9165 8010 |
| 94 |
Jabber: gsbarbieri@××××××.org |
| 95 |
ICQ#: 17249123 |
| 96 |
GPG: 0xB640E1A2 @ wwwkeys.pgp.net |
| 97 |
|
| 98 |
-- |
| 99 |
gentoo-portage-dev@g.o mailing list |
Archives