Gentoo Archives: gentoo-portage-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] Re: search functionality in emerge
Date: Mon, 24 Nov 2008 06:47:32
Message-Id: pan.2008.11.24.06.47.07@cox.net
In Reply to: Re: [gentoo-portage-dev] search functionality in emerge by devsk
1 devsk <funtoos@×××××.com> posted
2 396349.98307.qm@×××××××××××××××××××××××.com, excerpted below, on Sun, 23
3 Nov 2008 21:01:40 -0800:
4
5 > Why is a portage daemon such a bad thing? Or hard to do? I would very
6 > much like a daemon running on my system which I can configure to sync
7 > the portage tree once a week (or month if I am lazy), give me a summary
8 > of hot fixes, security fixes in a nice email, push important
9 > announcements and of course, sync caches on detecting changes (which
10 > should be trivial with notify daemons all over the place) etc. Why is it
11 > such a bad thing?
12 >
13 > Its crazy to think that security updates need to be pulled in Linux.
14
15 Well, this is more a user list discussion than a portage development
16 discussion, but...
17
18 For one thing, it's terribly inefficient to keep a dozen daemons running
19 checking only a single thing each, each week, when we have a cron
20 scheduling daemon, and it's both efficient and The Unix Way (R) to setup
21 a script to do whatever you need it to do, and then have the cron daemon
22 run each of a dozen different scripts once each week, instead of having
23 those dozen different daemons running constantly when they're only active
24 once a week.
25
26 IOW, it only requires a manual pull if you've not already setup cron to
27 invoke an appropriate script once a week, and that involves only a single
28 constantly running daemon, the cron daemon of your choice.
29
30 Now, perhaps it can be argued that there should be a package that
31 installs such a pre-made script. For all I know, maybe there is one
32 already. And perhaps it can be argued that said script, if optional,
33 should at least be mentioned in the handbook. I couldn't argue with the
34 logic of either of those. But there's no reason to run yet another
35 daemon constantly, when (1) it's not needed constantly, and (2), there's
36 already a perfectly functional way of scheduling something to run when
37 it /is/ needed, complete with optional results mailing, etc, if it's
38 scripted to do that.
39
40 --
41 Duncan - List replies preferred. No HTML msgs.
42 "Every nonfree program has a lord, a master --
43 and if you use the program, he is your master." Richard Stallman