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 1L6vvZ-00057v-V3 for garchives@archives.gentoo.org; Sun, 30 Nov 2008 23:42:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3CA96E0071; Sun, 30 Nov 2008 23:42:12 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by pigeon.gentoo.org (Postfix) with ESMTP id EDF84E0071 for ; Sun, 30 Nov 2008 23:42:11 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id v33so1077159wah.2 for ; Sun, 30 Nov 2008 15:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=PVETFY1piY0C7YyyxcTTL0esZ3zHJ8xTItqfXqE+pKY=; b=G0KpKnvhbCQNTxyERLMDmoY69+XTzOtrhJO0aRXeGBznlXxOPE/5v4R7SFOYmKUtnw zDgpP7byYHqEn5+PkCfB9bWrl8RXlonakJliO9lxAxnK1CFUSm/3OS1YUWz/uuEKXwnB lEU3bI1petlTTLH7a+f8SV+DZfPZWeaMYmKFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=HtqGjjqSXZW/pjB7uwMGyiZRC+6JaGpPyA9lW728OL/Am9Aw9pURSBj5O0M0lMpwhK udEtH8fz+Lr4B7TJ/RRm2PiPl/tOYr6+94VfuhWyFMkRPVCVwIOOtOfBVhr+LOse5RM8 TXIUdwO81B5JJPtLMU7Wa3Q1o+L+JM5HAey80= Received: by 10.115.16.14 with SMTP id t14mr6066090wai.185.1228088531509; Sun, 30 Nov 2008 15:42:11 -0800 (PST) Received: by 10.114.174.15 with HTTP; Sun, 30 Nov 2008 15:42:11 -0800 (PST) Message-ID: <5a8c638a0811301542s4aca92c3ie68ef427913c0523@mail.gmail.com> Date: Sun, 30 Nov 2008 18:42:11 -0500 From: "Emma Strubell" To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] search functionality in emerge In-Reply-To: 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: multipart/alternative; boundary="----=_Part_20041_27477770.1228088531508" References: <5a8c638a0811230417r5bcf912fka14a18edc9c711b6@mail.gmail.com> <4929C911.6090006@gentoo.org> <4929D240.1070306@necoro.eu> <492A7524.40108@necoro.eu> <20081124094820.GB7142@gentoo.org> <492AC52B.9080304@necoro.eu> X-Archives-Salt: 60e0439e-15bb-4c57-ab25-cbaddfa586eb X-Archives-Hash: 66d93292876c1a4e88b18db53b77b5f2 ------=_Part_20041_27477770.1228088531508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You guys all have some great ideas, but I don't think I'd have enough time to be able to implement them before my project is due... especially because they appear to be a bit beyond my current programming skills. I would love to devote a lot more time to this project, but I just can't right now because I already have a lot of other things on my plate. i am really interested in contributing to Gentoo and portage in the future, though. I'm thinking this summer I'll have a chance... Anyway, I'm going to try to keep it simple and just implement a suffix trie, and hope that that provides some measurable speed improvement :] Thanks again for everyone's help, though, and I'll definitely share the (amature and minimal, sorry!) results of my project if you're interested. Emma On Mon, Nov 24, 2008 at 12:15 PM, tvali wrote: > I take it shortly together as Rene didn't catch all and so I was fuzzy: > > Portage tree has automatically updateable parts, which should not changed > by user, and overlay, which will be. Thus, index of this automatic part > should be updated only after "emerge --sync". > > Speedup should contain custom filesystem, which would be called PortageFS, > for example. In initial version, PortageFS uses current portage tree and > generates additional indexes. > > So, when you bootup, you have portage tree in /usr/portage. At some point, > PortageFS is mounted into the same directory, /usr/portage. It will map real > /usr/portage directory into /usr/portage mount point and create some > additional folders like /usr/portage/search, which maps files to do real > searches. /usr/portage/handler would be a file, where you can write query > and read result. It also contains virtual files to check dependancies and > such stuff - many things you could use with your scripts. > > When it's mounted, every change is noticed and indexes will be > automagically updated (and sometimes after communication with portage - for > example, updates when doing "emerge --sync" should not happen automagically > maybe, as it makes things slower. When it's not mounted, you can change user > files, but must run some notification script afterwards maybe to rebuild > indexes. > > Indexes are built-in into FS. > > If PortageFS is not mounted, for example because of some emergency reboot, > portage can work without indexes, using real directory instead of this mount > point. > ------=_Part_20041_27477770.1228088531508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You guys all have some great ideas, but I don't think I'd have enough time to be able to implement them before my project is due... especially because they appear to be a bit beyond my current programming skills. I would love to devote a lot more time to this project, but I just can't right now because I already have a lot of other things on my plate. i am really interested in contributing to Gentoo and portage in the future, though. I'm thinking this summer I'll have a chance... Anyway, I'm going to try to keep it simple and just implement a suffix trie, and hope that that provides some measurable speed improvement :] Thanks again for everyone's help, though, and I'll definitely share the (amature and minimal, sorry!) results of my project if you're interested.

Emma

On Mon, Nov 24, 2008 at 12:15 PM, tvali <qtvali@gmail.com> wrote:
I take it shortly together as Rene didn't catch all and so I was fuzzy:

Portage tree has automatically updateable parts, which should not changed by user, and overlay, which will be. Thus, index of this automatic part should be updated only after "emerge --sync".

Speedup should contain custom filesystem, which would be called PortageFS, for example. In initial version, PortageFS uses current portage tree and generates additional indexes.

So, when you bootup, you have portage tree in /usr/portage. At some point, PortageFS is mounted into the same directory, /usr/portage. It will map real /usr/portage directory into /usr/portage mount point and create some additional folders like /usr/portage/search, which maps files to do real searches. /usr/portage/handler would be a file, where you can write query and read result. It also contains virtual files to check dependancies and such stuff - many things you could use with your scripts.

When it's mounted, every change is noticed and indexes will be automagically updated (and sometimes after communication with portage - for example, updates when doing "emerge --sync" should not happen automagically maybe, as it makes things slower. When it's not mounted, you can change user files, but must run some notification script afterwards maybe to rebuild indexes.

Indexes are built-in into FS.

If PortageFS is not mounted, for example because of some emergency reboot, portage can work without indexes, using real directory instead of this mount point.

------=_Part_20041_27477770.1228088531508--