public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Vitaly Kushneriuk <vitaly_kushneriuk@yahoo.com>
To: Gentoo-dev <gentoo-dev@gentoo.org>
Subject: [gentoo-dev] portage2 wish list
Date: 19 Dec 2001 11:09:14 +0200	[thread overview]
Message-ID: <1008752954.6145.4.camel@uranus.u235.eyep.net> (raw)

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.


                 reply	other threads:[~2001-12-19  9:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1008752954.6145.4.camel@uranus.u235.eyep.net \
    --to=vitaly_kushneriuk@yahoo.com \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox