Gentoo Archives: gentoo-dev

From: Vitaly Kushneriuk <vitaly_kushneriuk@×××××.com>
To: Gentoo-dev <gentoo-dev@g.o>
Subject: [gentoo-dev] portage2 wish list
Date: Wed, 19 Dec 2001 03:08:49
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 :-)
10 With no order of importance:
12 * auto package group search or something like "All"
13 directory in /portage/packages, but for ebuilds,
14 would be nice to have.
16 * Long package desciptions and way to read it.
17 ( other then "grep DESC /usr/portage/...ebuild" )
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.
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.
48 * some sane alternative to .keep files. They ARE ugly :-)
50 * change cryptic $P/A/S in ebuild to something meaningfull
51 ( SRCDIR/ PKGNAME etc. :-)
53 * way to autounmerge previous version of the package after
54 merging upgrade.
56 * warning when merging package that overwrites file from
57 other package ( not prev version )
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 )
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.
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...
82 * non root ebuilds?
84 * I'd like to be able to get a list packages that can use some "USE"
85 feature, but were compiled without it.
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".
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.
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.
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 )
117 P.S. Hmm.. the list seems prety dead lately... Holidays in US or
118 something?
120 Thanks in advance.