Re: Interest inquery: kde4-nosemantic overlay

Duncan wrote:
> Martin Vaeth posted:
> > Does your framework manage the ebuilds in some overlay, or is it
> > actually running tranparently during emerge (probably with a patched
> > version of portage), allowing e.g. to change metadata without
> > maintaining the ebuild in a separate local overlay?
> > (I guess that it is the former, but your choice of the path
> > /etc/portage/... suggests the latter)
 
> the framework I've setup is repo agnostic and would find the ebuilds in
> whatever repo, main tree or active overlay, they appear in.

> I've occasionally been frustrated by this, but until this gentoo/kde 
> semantic-desktop policy change, particularly with epatch_user eliminating 
> the need for most of the ebuild edits I used to do, it was just easier to 
> do the manual hacking any time I needed to change an actual ebuild.

Hmm why was a local overlay inappropriate? I thought you could mask packages
from specific overlays (or am i wrong about that?)

Not that it matters, in that I'm glad you've gone down this path. I'd just
like to know.

From what you've written, the first thing that springs to mind is
/etc/portage/postsync.d/ which has q-reinitialize in it. I have that activated,
and run eix-sync after emerge --sync in update, which takes care of overlays.
Which answers why postsync isn't sufficient in and of itself. Hmm I guess that
means that means qgrep et al aren't complete, which I've never noticed as I don't
use overlays.

Additionally, like Martin, I assumed you were doing this in a local overlay, not
on the tree itself, with resultant rsync wipeout. So if we can sort that out, by
writing the output to:
 "${local_overlay:=/usr/local/portage}/${ebuild#"$PORTDIR"}"
I'd be a lot happier. It'll fit much better in the process of pushing to an
external overlay as well.

The other thing I was going to mention is that update -s wraps the whole process,
to filter the rsync output so it's only one line (the performance thing I mentioned
in the other post: I never expected that to work so well but my mentor does the awk
so I just tried in bash, and was amazed. :) So we could:
a) get the list of ebuilds that have actually been changed via rsync, or
b) check what eix is reporting after (if the user has eix.)

However a postsync action similar to q would be the best; it just has to run after
the overlays have been sync'ed. As I said I don't use overlays, so it's up to you
and people like Martin to work the details of 'what and when' out. I'll help with
the 'how'. I'd just prefer something that doesn't require a wrapper, but works with
any emerge setup.

Alternatively, if we can get eix to do it directly, it'd rock afaic. Though a
developer I know refuses to use it, as he says it takes too long if you've got
a cvs tree, or sth. Unfortunately, like you, mv doesn't do IRC, so I've not been
able to get the two together for a chat to see if anything could be sorted, or
whether it's intractable.

Personally, I'm fine with a dep on eix fwiw.

I'm reasonably sure you can hook whatever you like into eix-sync, as I recall
telling people to just use it quite a lot back in the day (we do have postSync
actions as well, one for -q quiet usage, if defined) but mv can tell us more, if
eix can help. It seems the right spot, since eix-sync can run after emerge --sync
and do all the overlays, so people are used to running it. iirc again you can use
a postsync.d action, so it would be ideal.

We just don't with update as we want the rsync filtering, and have to work when
the user doesn't have eix, so it's always been separate. Having said that, if the
user has eix running in postsync, that'll work too.

That's the trouble with glue-scripting: you have to consider the interaction of
quite a few disparate commands, and various end-user setups.

It's also what makes it useful, and fun to work on. :-)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)