From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DMARC_REJECT,FORGED_YAHOO_RCVD,FREEMAIL_FROM,MAILING_LIST_MULTI, RDNS_NONE,SPOOFED_FREEMAIL_NO_RDNS autolearn=no autolearn_force=no version=4.0.0 Received: from uranus.u235.eyep.net (unknown [194.90.113.98]) by chiba.3jane.net (Postfix) with SMTP id 0EE5E24647 for ; Wed, 19 Dec 2001 03:08:49 -0600 (CST) Received: (qmail 22744 invoked by uid 1000); 19 Dec 2001 09:09:14 -0000 From: Vitaly Kushneriuk To: Gentoo-dev Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 19 Dec 2001 11:09:14 +0200 Message-Id: <1008752954.6145.4.camel@uranus.u235.eyep.net> Mime-Version: 1.0 Subject: [gentoo-dev] portage2 wish list Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Developer discussion list List-Unsubscribe: , List-Archive: X-Archives-Salt: 3111be21-aac0-4119-a573-c3d6bfa8eb69 X-Archives-Hash: e7631e9a2d57babb4ea8515b840c1aee Greets. Sorry for a long email, but I'd like to share some thoughts and (I wish) get some comments. First of all, keep up with the great work. I love Gentoo :-). I understand, portage 2 is under development. As there's no wish list or bug tracking system, I decided to post my wish list here. This is just my personal wish list :-) With no order of importance: * auto package group search or something like "All" directory in /portage/packages, but for ebuilds, would be nice to have. * Long package desciptions and way to read it. ( other then "grep DESC /usr/portage/...ebuild" ) * It would be nice to have some portage db query tool. I know there's pkgsearch/pkglist etc. but they are not allways correct, incomplete etc. The operations/fixes I'd like to see in this tool: 1) BUGFIX: pkgsearch should show installed version even if it's ebuild is removed from /usr/portage/ (it's still in /var/db/pkg/) and should be much faster. 2) query for file owner. i.e. which package owns the file. 3) check package integrity: check all files of the package for mtime and (optionaly, as it's slow) md5 change. full listing and summary mode 4) List all files in the packages 5) print package info ( url, homepage, description ) I use pkgsearch/"grep HOME ...ebuild" but it's inconvinient :-) 6) Check for packages that own same file. 7) list of all the packages dependant on give package. with option to show only those, that older then the package, so that I can rebuild packages that depend on library when the lib changes. I made myself shell scripts for most of the above, but they are just a "quick & dirty" solution, not suitable for release. I also know that some of the functionality is allready there in tolls like pkgsearch/pkglist, but they are incomplete/undocumented. * some sane alternative to .keep files. They ARE ugly :-) * change cryptic $P/A/S in ebuild to something meaningfull ( SRCDIR/ PKGNAME etc. :-) * way to autounmerge previous version of the package after merging upgrade. * warning when merging package that overwrites file from other package ( not prev version ) * way to set --usepkg --buildpkg in make.conf ( I hacked portage for this, but I think others could benefit from this too ) * BUG? I posted this few days ago, but didn't get any reply: IMHO portage should use user names and not UIDs when extracting files from prebuild binary packages. * OK This one I think is VERY important: after every "emerge rsync" I check "emerge --pretend --noreplace update" to see what packages are updated. Then I start diff-ing ebuilds(in a cese of a newer ebuild) or unpacking/reading changelog(in a case of new package version) to see what changed to decide if I should upgrade. Separate change logs for both the package itself and for ebuild releases would be VERY helpfull for an average SA which has no time to check websites/unpack every packeage etc. ( change log for ebuilds can be started from scratch with every new package version) IMHO it should have some unified ofrmat to enable future gui tools auto scripts to deal with it. Field I'd like to see there: reason=cosmetic(ebuild)|security(both)|new feature[s](package) etc... * non root ebuilds? * I'd like to be able to get a list packages that can use some "USE" feature, but were compiled without it. * Usualy there's a lot of additional options that can be passed to configure at compile time, to enable/disable additional features, I'd like to be able to pass them to emerge, and not "ebuild unpack"/manual compile/"ebuild merge". It would be great if the list+descriptions of this features were included with ebuild ( afte all, the maintainer is supposed to read the INSTALL file and run ./configure --help :-), so it will not take more then 2 min.(+ a few minutes to comment, if he wants to make the best) to copy-paste this options to the ebuild, but will save a lot of time to SA's that want to optimize their systems even further. * As an extention to the previous, I thoufght about something like following: For every ebuild, there's a list of configurabe features (name+description). If OPCONFIG is set in make.conf or some runtime option is set, emerge will ask SA to answer if he wants this features included. It will remember the answers and use them in the next ebuild for the same package ( if feature name is unchanged ). Some kernel-make-config like system would be most useful for SA that want's to have realy TOTAL control over system, but doesn't want to compile every package manualy. * Some desidion documentation would be nice. I'd like to know Whey that patch is there etc. BTW, having "low latency" patch AND "preemptive kernel" together looks like overkill ( I haven't followed kernel stuff for long enough, so I don't know ) P.S. Hmm.. the list seems prety dead lately... Holidays in US or something? Thanks in advance.