Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] post_sync actions
Date: Sun, 30 Oct 2005 06:09:01
Message-Id: 20051030060817.GB6443@nightcrawler
In Reply to: Re: [gentoo-portage-dev] [PATCH] post_sync actions by Jason Stubbs
1 On Sun, Oct 30, 2005 at 02:47:51PM +0900, Jason Stubbs wrote:
2 > > post sync has a limited shelf life; it's usable now for the following
3 > > 1) rolling gensync functionality in
4 > > 2) rolling glsa notices on sync in
5 > > 3) rolling package watch lists of updates in
6 > > 4) a method to trigger transfer of an rsync temp dir on a rsync proxy
7 > > for a lan to the actual directory rsyncd distributes from.
8 >
9 > 1, 2 and 3 are slated for inclusion. What will happen with 4 and other similar
10 > site-specific hooks?
11
12 My intention for post sync is to ignore it for 3.0 code.
13
14 Reasoning pretty much comes down to the fact it's a general hook; we
15 have no way of knowing if they're triggering cache generation,
16 arbitrary repo syncing, package scans, etc.
17
18 That's not to say that hooking code in won't be possible, just that
19 post sync in it's current form I view as strictly a 2.x thing; so...
20 for #4, how I'd probably implement it in 3.0 would be a treeset,
21
22 rsync repo,
23 rsyncd share point repo
24
25 with the sync calls chained; basically a slaved repo.
26
27 Intend to do similar tricks with slaving the cache for ospreyon a
28 sidenote.
29
30 Either way, configuration will allow something to be done, although
31 again, post sync won't be the route, will have to specify the wrappers
32 per repo (and potentially do some trickery for #4 in your config).
33 ~harring

Replies

Subject Author
Re: [gentoo-portage-dev] [PATCH] post_sync actions Jason Stubbs <jstubbs@g.o>