| 1 |
Greets. |
| 2 |
Sorry for a long email, but I'd like to share some thoughts and |
| 3 |
(I wish) get some comments. |
| 4 |
First of all, keep up with the great work. I love Gentoo :-). |
| 5 |
I understand, portage 2 is under development. |
| 6 |
As there's no wish list or bug tracking system, I decided |
| 7 |
to post my wish list here. |
| 8 |
This is just my personal wish list :-) |
| 9 |
|
| 10 |
With no order of importance: |
| 11 |
|
| 12 |
* auto package group search or something like "All" |
| 13 |
directory in /portage/packages, but for ebuilds, |
| 14 |
would be nice to have. |
| 15 |
|
| 16 |
* Long package desciptions and way to read it. |
| 17 |
( other then "grep DESC /usr/portage/...ebuild" ) |
| 18 |
|
| 19 |
* It would be nice to have some portage db query tool. |
| 20 |
I know there's pkgsearch/pkglist etc. but they are |
| 21 |
not allways correct, incomplete etc. The operations/fixes |
| 22 |
I'd like to see in this tool: |
| 23 |
1) BUGFIX: pkgsearch should show installed version |
| 24 |
even if it's ebuild is removed from /usr/portage/ |
| 25 |
(it's still in /var/db/pkg/) and should be much faster. |
| 26 |
2) query for file owner. i.e. which package |
| 27 |
owns the file. |
| 28 |
3) check package integrity: check all files of the package |
| 29 |
for mtime and (optionaly, as it's slow) md5 change. full listing |
| 30 |
and summary mode |
| 31 |
4) List all files in the packages |
| 32 |
5) print package info ( url, homepage, description ) |
| 33 |
I use pkgsearch/"grep HOME ...ebuild" but it's |
| 34 |
inconvinient :-) |
| 35 |
6) Check for packages that own same file. |
| 36 |
7) list of all the packages dependant on give package. |
| 37 |
with option to show only those, that older then |
| 38 |
the package, so that I can rebuild packages that |
| 39 |
depend on library when the lib changes. |
| 40 |
|
| 41 |
I made myself shell scripts for most of the above, but |
| 42 |
they are just a "quick & dirty" solution, not suitable |
| 43 |
for release. |
| 44 |
I also know that some of the functionality |
| 45 |
is allready there in tolls like pkgsearch/pkglist, but |
| 46 |
they are incomplete/undocumented. |
| 47 |
|
| 48 |
* some sane alternative to .keep files. They ARE ugly :-) |
| 49 |
|
| 50 |
* change cryptic $P/A/S in ebuild to something meaningfull |
| 51 |
( SRCDIR/ PKGNAME etc. :-) |
| 52 |
|
| 53 |
* way to autounmerge previous version of the package after |
| 54 |
merging upgrade. |
| 55 |
|
| 56 |
* warning when merging package that overwrites file from |
| 57 |
other package ( not prev version ) |
| 58 |
|
| 59 |
* way to set --usepkg --buildpkg in make.conf |
| 60 |
( I hacked portage for this, but I think others could benefit |
| 61 |
from this too ) |
| 62 |
|
| 63 |
* BUG? I posted this few days ago, but didn't get any reply: |
| 64 |
IMHO portage should use user names and not UIDs when extracting |
| 65 |
files from prebuild binary packages. |
| 66 |
|
| 67 |
* OK This one I think is VERY important: |
| 68 |
after every "emerge rsync" I check |
| 69 |
"emerge --pretend --noreplace update" to see what packages are |
| 70 |
updated. Then I start diff-ing ebuilds(in a cese of a newer ebuild) |
| 71 |
or unpacking/reading changelog(in a case of new package version) |
| 72 |
to see what changed to decide if I should upgrade. |
| 73 |
Separate change logs for both the package itself and for ebuild |
| 74 |
releases would be VERY helpfull for an average SA which has |
| 75 |
no time to check websites/unpack every packeage etc. |
| 76 |
( change log for ebuilds can be started from scratch |
| 77 |
with every new package version) |
| 78 |
IMHO it should have some unified ofrmat to enable future gui tools |
| 79 |
auto scripts to deal with it. Field I'd like to see there: |
| 80 |
reason=cosmetic(ebuild)|security(both)|new feature[s](package) etc... |
| 81 |
|
| 82 |
* non root ebuilds? |
| 83 |
|
| 84 |
* I'd like to be able to get a list packages that can use some "USE" |
| 85 |
feature, but were compiled without it. |
| 86 |
|
| 87 |
* Usualy there's a lot of additional options that can be |
| 88 |
passed to configure at compile time, to enable/disable additional |
| 89 |
features, I'd like to be able to pass them to emerge, and not |
| 90 |
"ebuild unpack"/manual compile/"ebuild merge". |
| 91 |
|
| 92 |
It would be great if the list+descriptions of this features |
| 93 |
were included with ebuild ( afte all, the maintainer is supposed to |
| 94 |
read the INSTALL file and run ./configure --help :-), so it will |
| 95 |
not take more then 2 min.(+ a few minutes to comment, if he wants |
| 96 |
to make the best) to copy-paste this options to the ebuild, |
| 97 |
but will save a lot of time to SA's that want to optimize their |
| 98 |
systems even further. |
| 99 |
|
| 100 |
* As an extention to the previous, I thoufght about something like |
| 101 |
following: |
| 102 |
For every ebuild, there's a list of configurabe features |
| 103 |
(name+description). If OPCONFIG is set in make.conf or some |
| 104 |
runtime option is set, emerge will ask SA to answer if he wants |
| 105 |
this features included. It will remember the answers and use |
| 106 |
them in the next ebuild for the same package ( if feature name is |
| 107 |
unchanged ). Some kernel-make-config like system would be most |
| 108 |
useful for SA that want's to have realy TOTAL control over system, |
| 109 |
but doesn't want to compile every package manualy. |
| 110 |
|
| 111 |
* Some desidion documentation would be nice. I'd like to know |
| 112 |
Whey that patch is there etc. |
| 113 |
BTW, having "low latency" patch AND "preemptive kernel" together |
| 114 |
looks like overkill ( I haven't followed kernel stuff for long |
| 115 |
enough, so I don't know ) |
| 116 |
|
| 117 |
P.S. Hmm.. the list seems prety dead lately... Holidays in US or |
| 118 |
something? |
| 119 |
|
| 120 |
Thanks in advance. |
Archives