Re: Interest inquery: kde4-nosemantic overlay

Duncan <[email protected]> wrote:
>
> I do have a local overlay, and use it for one-offs

You can have several local overlays, one particularly dedicated for KDE
(and if you put the directory of the latter under git control,
you could also easily make it public e.g. on GitHub so that other users
can use it without using your framework).

> But in the kde case that wouldn't work as the patches will need to be
> reapplied long-term -- no upstream inclusion, as I didn't want to deal
> with manually overlaying/patching every single revision bump, etc.
> [...] So applying the patches direct-in-repo made most sense for me

Why not use the script to patch the ebuilds after fetching
but store the patched ebuilds in your dedicated overlay instead
of the original location?
If you give this dedicated overlay a higher priority in
/etc/portage/repos.conf, portage will install the patched
ebuilds if they are available.

For a general framework, one could e.g. support directories
of the form

/etc/portage/ebuild.patches/FROM:TO/whatever

so that "whatever" (patches, sed-commands, etc; depends how
your framework works) is applied by your framework after
it copied the corresponding ebuild from repository FROM to TO.
In particular, currently you would use only something like

/etc/portage/ebuild.patches/kde-experimental:kde_unsemantic/...

The scripts in your framework can use functions like
	portageq get_repo_path / FROM
or the quicker new
	eix-header -p FROM
to find out the corresponding paths, once these repositories
are set up (and in the eix database, respectively).

> There's also the fact that my patches change dependencies -- that's what
> they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus
> invalidating portage's metadata cache, so if emerge --regen isn't
> triggered afterward, every emerge invocation will take longer.

For a local overlay you do not need to run emerge --regen. Running

egencache --repo=kde_unsemantic --update --update-use-local-desc

after applying the patches is sufficient: If kde_unsemantic has
a higher priority in /etc/portage/repos.conf, its metadata will
be taken.
BTW, I would suggest to put into metadata/layout.conf of
kde_unsemantic the lines

cache-formats = md5-dict
thin-manifests = true

and if you use git also into .gitignore the line

/metadata/md5-cache/

so that users have to run the above egencache command on their own
(which is better than having possibly outdated checksums for
eclasses in which case md5-cache would not help them, anyway).

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

That's why for end-users publishing the patched overlay would
be better: They can still come up with patches anyway, i.e.
they are not even excluded from development if they do not use
your framework.