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 <gentoo-portage-dev+bounces-2162-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1L4UtS-0004cr-T9
	for garchives@archives.gentoo.org; Mon, 24 Nov 2008 06:25:59 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id DB999E049A;
	Mon, 24 Nov 2008 06:25:58 +0000 (UTC)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188])
	by pigeon.gentoo.org (Postfix) with ESMTP id 65D9DE049A
	for <gentoo-portage-dev@lists.gentoo.org>; Mon, 24 Nov 2008 06:25:58 +0000 (UTC)
Received: from sheridan (dslb-088-070-220-113.pools.arcor-ip.net [88.70.220.113])
	by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis)
	id 0ML29c-1L4UtP1rWZ-0003Ab; Mon, 24 Nov 2008 07:25:55 +0100
Date: Mon, 24 Nov 2008 07:25:22 +0100
From: Marius Mauch <genone@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] search functionality in emerge
Message-Id: <20081124072522.4f475b28.genone@gentoo.org>
In-Reply-To: <396349.98307.qm@web31708.mail.mud.yahoo.com>
References: <5a8c638a0811230417r5bcf912fka14a18edc9c711b6@mail.gmail.com>
	<20081124041257.755679eb.genone@gentoo.org>
	<396349.98307.qm@web31708.mail.mud.yahoo.com>
X-Mailer: Sylpheed 2.4.8 (GTK+ 2.10.14; i686-pc-mingw32)
Precedence: bulk
List-Post: <mailto:gentoo-portage-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-portage-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-portage-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-portage-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-portage-dev.gentoo.org>
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=US-ASCII
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX18a5TGDsdp3MAsa3GtIXIPc1qZe9qKNoNr0qZs
 URwnqCYsOFB4O2UUT5sMBoGx+zx4ADsqAic26YdrSx+A1RmG0q
 7KwhzYzpBAKPShsFtz96Q==
X-Archives-Salt: 3ace3129-e039-4a11-a112-1e14ddfa47b6
X-Archives-Hash: a13cf96b0bbb43a69746e185624916e8

On Sun, 23 Nov 2008 21:01:40 -0800 (PST)
devsk <funtoos@yahoo.com> wrote:

> > not relying on custom system daemonsrunning in the background.
> 
> Why is a portage daemon such a bad thing? Or hard to do? I would very
> much like a daemon running on my system which I can configure to sync
> the portage tree once a week (or month if I am lazy), give me a
> summary of hot fixes, security fixes in a nice email, push important
> announcements and of course, sync caches on detecting changes (which
> should be trivial with notify daemons all over the place) etc. Why is
> it such a bad thing?

Well, as an opt-in solution it might work (though most of what you
described is IMO just stuff for cron, no need to reinvent the wheel).

What I was saying is that _relying_ on custom system
daemons/filesystems for a _core subsystem_ of portage is the wrong
way, simply because it adds a substantial amount of complexity to the
whole package management architecture. It's one more thing that can
(and will) break, one more layer to take into account for any design
decisions, one more component that has to be secured, one more obstacle
to overcome when you want to analyze/debug things.
And special care must be taken if it requires special kernel support
and/or external packages. Do you want to make inotify support mandatory
to use portage efficiently? (btw, looks like inotify doesn't really
work with NFS mounts, which would already make such a daemon completely
useless for people using a NFS-shared repository)

And finally, if you look at the use cases, a daemon is simply overkill
for most cases, as the vast majority of people only use emerge
--sync (or wrappers) and maybe layman to change the tree, usually once
per day or less often. Do you really want to push another system daemon
on users that isn't of use to them?

> Its crazy to think that security updates need to be pulled in Linux.

That's IMO better be handled via an applet (bug #190397 has some code),
or just check for updates after a sync (as syncing is the only
way for updates to become available at this time). Maybe a message
could be added after sync if there are pending GLSAs, now that the glsa
support code is in portage.

Marius