Martin Vaeth wrote:
> Duncan 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).
git clone git@weaver.gentooexperimental.org:kde-lean
I add eg: --separate-git-dir=$HOME/repo/git/kde-lean.git # for things I'll be
working on: it just means I have a bare repo kept safe to one side, no matter
what I mess up in my workdir (and I can rm -f it easily if I should feel to.)
Nothing in there of course, but I followed your instructions wrt setup, mv.
Oh, and added a repo_name.
If you email me your/an ssh-pubkey, I'll setup write-access.
The trac is here:
http://weaver.gentooexperimental.org/trac/kde-lean
You need to register and login to browse the source, as we have to be careful
of excess CPU and network usage, since it's Patrick's infra, and we don't want
to be unwelcome guests. Benefit is we don't have to sign away anyone's rights
to github for the rest of time.
Bugs can be browsed and searched, as well as the wiki, ofc.
> > 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.
Perhaps not manually, but that's exactly what is happening here. So doing
it in another output directory is no different: it just means you can run
a diff easily, and you don't need to overwrite the local portage mirror.
> > [...] 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.
We can also supply a kde-lean.mask file that can either be dropped into
a directory package.mask, or simply:
cat kde-lean.mask >> /etc/portage/package.mask
So we can mask eg: kde-base/kdelibs:4::gentoo given that it's not currently
available in overlay profiles/ (or wasn't last time I saw it discussed in
#-portage, at least. IIRC there's a "philosophical" objection, so I wouldn't
hold my breath.;)
There's really not that many packages that even have the semantic-desktop
flag; equery hasuse -p semantic-desktop # (slow) got me the list here:
http://weaver.gentooexperimental.org/trac/kde-lean/roadmap
> For a general framework, one could e.g. support directories
> of the form
>
> /etc/portage/ebuild.patches/FROM:TO/whatever
I'm assuming whatever is the usual specifier, from most specific to least,
ie: $PVR -> $CPN. Just so it's in the spec from dot.
> 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/...
s/kde_unsemantic/kde-lean/g
Though if we're doing this for an overlay, FROM should be gentoo. Irrelevant
to the implementation, I know. Speaking of which:
http://weaver.gentooexperimental.org/trac/ebuild-patch
(same git address as above.) If you register on either, your login will be in the
passwd database, but you will need to login to the other trac (with the same
uid/password of course) for the account to be setup therein.
If you intend to commit, using the same email for your account, as for your
commits is supposed to link the two in the trac-vcs browser. (though that may only
work properly in svn, as it doesn't seem to apply to my commit to initialise the
repo, which was needed for gitolite to start managing it.) Regardless, your
email can be changed after, if it's an issue, though again it applies site-wide.
> 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).
I'd prefer a straightforward, shlex-compatible config file personally. That makes
it quick for a sh-based implementation, across the board. It's easy enough to check
that {make,layman}.conf haven't changed, and to use the slower setup then.
> > Steven J. Long posted:
> > > From what you've written, the first thing that springs to mind is
> > > /etc/portage/postsync.d/ which has q-reinitialize in it.
> > 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.
Can we do this in a postsync.d hook, both one that runs eix and one that
does not? Pseudo-code of the algorithm you'd use in both cases would be
ideal. Well, sh of the top-level would be /ideal/.. ;p
> BTW, I would suggest to put into metadata/layout.conf of
> [kde-lean;] 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).
Lovely, followed to the letter.
> >> 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.
Indeed.
Seems apparent we need to get to milestone 0.2 for ebuild-patch
before we can think of publishing an overlay. 0.1 is up to Duncan: base
just means the initial impl of stage 4, in a state that he's happy for the
ROTW to see ;)
Regards,
steveL.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
> Duncan 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).
git clone git@weaver.gentooexperimental.org:kde-lean
I add eg: --separate-git-dir=$HOME/repo/git/kde-lean.git # for things I'll be
working on: it just means I have a bare repo kept safe to one side, no matter
what I mess up in my workdir (and I can rm -f it easily if I should feel to.)
Nothing in there of course, but I followed your instructions wrt setup, mv.
Oh, and added a repo_name.
If you email me your/an ssh-pubkey, I'll setup write-access.
The trac is here:
http://weaver.gentooexperimental.org/trac/kde-lean
You need to register and login to browse the source, as we have to be careful
of excess CPU and network usage, since it's Patrick's infra, and we don't want
to be unwelcome guests. Benefit is we don't have to sign away anyone's rights
to github for the rest of time.
Bugs can be browsed and searched, as well as the wiki, ofc.
> > 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.
Perhaps not manually, but that's exactly what is happening here. So doing
it in another output directory is no different: it just means you can run
a diff easily, and you don't need to overwrite the local portage mirror.
> > [...] 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.
We can also supply a kde-lean.mask file that can either be dropped into
a directory package.mask, or simply:
cat kde-lean.mask >> /etc/portage/package.mask
So we can mask eg: kde-base/kdelibs:4::gentoo given that it's not currently
available in overlay profiles/ (or wasn't last time I saw it discussed in
#-portage, at least. IIRC there's a "philosophical" objection, so I wouldn't
hold my breath.;)
There's really not that many packages that even have the semantic-desktop
flag; equery hasuse -p semantic-desktop # (slow) got me the list here:
http://weaver.gentooexperimental.org/trac/kde-lean/roadmap
> For a general framework, one could e.g. support directories
> of the form
>
> /etc/portage/ebuild.patches/FROM:TO/whatever
I'm assuming whatever is the usual specifier, from most specific to least,
ie: $PVR -> $CPN. Just so it's in the spec from dot.
> 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/...
s/kde_unsemantic/kde-lean/g
Though if we're doing this for an overlay, FROM should be gentoo. Irrelevant
to the implementation, I know. Speaking of which:
http://weaver.gentooexperimental.org/trac/ebuild-patch
(same git address as above.) If you register on either, your login will be in the
passwd database, but you will need to login to the other trac (with the same
uid/password of course) for the account to be setup therein.
If you intend to commit, using the same email for your account, as for your
commits is supposed to link the two in the trac-vcs browser. (though that may only
work properly in svn, as it doesn't seem to apply to my commit to initialise the
repo, which was needed for gitolite to start managing it.) Regardless, your
email can be changed after, if it's an issue, though again it applies site-wide.
> 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).
I'd prefer a straightforward, shlex-compatible config file personally. That makes
it quick for a sh-based implementation, across the board. It's easy enough to check
that {make,layman}.conf haven't changed, and to use the slower setup then.
> > Steven J. Long posted:
> > > From what you've written, the first thing that springs to mind is
> > > /etc/portage/postsync.d/ which has q-reinitialize in it.
> > 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.
Can we do this in a postsync.d hook, both one that runs eix and one that
does not? Pseudo-code of the algorithm you'd use in both cases would be
ideal. Well, sh of the top-level would be /ideal/.. ;p
> BTW, I would suggest to put into metadata/layout.conf of
> [kde-lean;] 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).
Lovely, followed to the letter.
> >> 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.
Indeed.
Seems apparent we need to get to milestone 0.2 for ebuild-patch
before we can think of publishing an overlay. 0.1 is up to Duncan: base
just means the initial impl of stage 4, in a state that he's happy for the
ROTW to see ;)
Regards,
steveL.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)