From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L9BfE-0003DB-N4 for garchives@archives.gentoo.org; Sun, 07 Dec 2008 04:54:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DEE6CE03DE; Sun, 7 Dec 2008 04:54:39 +0000 (UTC) Received: from mail-fx0-f21.google.com (mail-fx0-f21.google.com [209.85.220.21]) by pigeon.gentoo.org (Postfix) with ESMTP id 8022BE03DE for ; Sun, 7 Dec 2008 04:54:39 +0000 (UTC) Received: by fxm14 with SMTP id 14so24049fxm.10 for ; Sat, 06 Dec 2008 20:54:38 -0800 (PST) Received: by 10.223.105.68 with SMTP id s4mr920053fao.10.1228625678624; Sat, 06 Dec 2008 20:54:38 -0800 (PST) Received: by 10.223.112.17 with HTTP; Sat, 6 Dec 2008 20:54:38 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 13:54:38 +0900 From: "Douglas Anderson" To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] Re: equery refactorization In-Reply-To: <20081207052602.2d58f0f6.genone@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <493B3CAD.9070304@smith-li.com> <493B4428.50907@smith-li.com> <20081207052602.2d58f0f6.genone@gentoo.org> X-Archives-Salt: afbf99f1-d415-4511-9792-927c3cc99bf8 X-Archives-Hash: dd34fc8afe6543a97a788432b27dda35 On Sun, Dec 7, 2008 at 1:26 PM, Marius Mauch wrote: > On Sun, 7 Dec 2008 12:44:25 +0900 > "Douglas Anderson" wrote: > >> I also thought about renaming the "list(l)" option as "search", >> because if you look at the help output, almost every module "lists" >> something. equery's "list" is actually a search, I don't see why we >> shouldn't name it that. I think maybe list was used because there were >> already two "s" options, stats and size. Stats is not implemented so >> I'm taking it out of help for now. Size can use the short "z", becaues >> that's quite unique. That would free up "s" for search and it would be >> a whole lot clearer. >> >> Yes? No? > > No. "search" (if used at all) should be reserved for a more > comprehensive search framework (though IMO a separate tool for that is > more appropriate), not just a simple name match. "list" makes sense if > you consider that the pkgspec argument is optional, and one of the main > tasks of it is to simply list the packages in the given repository > (that's why vardb is also the default for it) without further filtering. > > Also one of the main goals of equery (according to karltk, the original > author) was to have a stable user interface, compared to the deprecated > qpkg and etcat scripts. And while the equery interface isn't exactly > the best I've seen it has been stable, so you might want to think twice > before renaming options and eventually pissing off users or breaking > third-party scripts. > > Marius > > $ equery list -h List all packages matching a query pattern Syntax: list pkgspec is either of: -i, --installed - search installed packages (default) -I, --exclude-installed - do not search installed packages -p, --portage-tree - also search in portage tree (/usr/portage) -o, --overlay-tree - also search in overlay tree (/usr/portage/local/layman/wschlich-testing /usr/portage/local/layman/xwing /usr/portage/local/layman/genscripts /usr/portage/local/layman/wschlich-testing /usr/portage/local/layman/xwing /usr/portage/local/layman/genscripts /usr/local/portage) -f, --full-regex - query is a regular expression -e, --exact-name - list only those packages that exactly match -d, --duplicates - list only installed duplicate packages That's an awful lot of "searching" there for something that's definitely not a search. List is really ambiguous, but whatever. I understand the point of having a stable interface, but this is probably the most widely recommended tool on the forums and #gentoo. Stability is not a good enough reason to let it bit rot. Wasn't a more unified tool interface also one of the original goals of gentoolkit? -Doug