1 |
Martin Vaeth wrote: |
2 |
> Duncan wrote: |
3 |
> > I do have a local overlay, and use it for one-offs |
4 |
> |
5 |
> You can have several local overlays, one particularly dedicated for KDE |
6 |
> (and if you put the directory of the latter under git control, |
7 |
> you could also easily make it public e.g. on GitHub so that other users |
8 |
> can use it without using your framework). |
9 |
|
10 |
git clone git@×××××××××××××××××××××××××.org:kde-lean |
11 |
|
12 |
I add eg: --separate-git-dir=$HOME/repo/git/kde-lean.git # for things I'll be |
13 |
working on: it just means I have a bare repo kept safe to one side, no matter |
14 |
what I mess up in my workdir (and I can rm -f it easily if I should feel to.) |
15 |
|
16 |
Nothing in there of course, but I followed your instructions wrt setup, mv. |
17 |
Oh, and added a repo_name. |
18 |
|
19 |
If you email me your/an ssh-pubkey, I'll setup write-access. |
20 |
|
21 |
The trac is here: |
22 |
http://weaver.gentooexperimental.org/trac/kde-lean |
23 |
|
24 |
You need to register and login to browse the source, as we have to be careful |
25 |
of excess CPU and network usage, since it's Patrick's infra, and we don't want |
26 |
to be unwelcome guests. Benefit is we don't have to sign away anyone's rights |
27 |
to github for the rest of time. |
28 |
|
29 |
Bugs can be browsed and searched, as well as the wiki, ofc. |
30 |
|
31 |
> > But in the kde case that wouldn't work as the patches will need to be |
32 |
> > reapplied long-term -- no upstream inclusion, as I didn't want to deal |
33 |
> > with manually overlaying/patching every single revision bump, etc. |
34 |
|
35 |
Perhaps not manually, but that's exactly what is happening here. So doing |
36 |
it in another output directory is no different: it just means you can run |
37 |
a diff easily, and you don't need to overwrite the local portage mirror. |
38 |
|
39 |
> > [...] So applying the patches direct-in-repo made most sense for me |
40 |
> |
41 |
> Why not use the script to patch the ebuilds after fetching |
42 |
> but store the patched ebuilds in your dedicated overlay instead |
43 |
> of the original location? |
44 |
> If you give this dedicated overlay a higher priority in |
45 |
> /etc/portage/repos.conf, portage will install the patched |
46 |
> ebuilds if they are available. |
47 |
|
48 |
We can also supply a kde-lean.mask file that can either be dropped into |
49 |
a directory package.mask, or simply: |
50 |
cat kde-lean.mask >> /etc/portage/package.mask |
51 |
|
52 |
So we can mask eg: kde-base/kdelibs:4::gentoo given that it's not currently |
53 |
available in overlay profiles/ (or wasn't last time I saw it discussed in |
54 |
#-portage, at least. IIRC there's a "philosophical" objection, so I wouldn't |
55 |
hold my breath.;) |
56 |
|
57 |
There's really not that many packages that even have the semantic-desktop |
58 |
flag; equery hasuse -p semantic-desktop # (slow) got me the list here: |
59 |
http://weaver.gentooexperimental.org/trac/kde-lean/roadmap |
60 |
|
61 |
> For a general framework, one could e.g. support directories |
62 |
> of the form |
63 |
> |
64 |
> /etc/portage/ebuild.patches/FROM:TO/whatever |
65 |
|
66 |
I'm assuming whatever is the usual specifier, from most specific to least, |
67 |
ie: $PVR -> $CPN. Just so it's in the spec from dot. |
68 |
|
69 |
> so that "whatever" (patches, sed-commands, etc; depends how |
70 |
> your framework works) is applied by your framework after |
71 |
> it copied the corresponding ebuild from repository FROM to TO. |
72 |
> In particular, currently you would use only something like |
73 |
> |
74 |
> /etc/portage/ebuild.patches/kde-experimental:kde_unsemantic/... |
75 |
|
76 |
s/kde_unsemantic/kde-lean/g |
77 |
|
78 |
Though if we're doing this for an overlay, FROM should be gentoo. Irrelevant |
79 |
to the implementation, I know. Speaking of which: |
80 |
|
81 |
http://weaver.gentooexperimental.org/trac/ebuild-patch |
82 |
(same git address as above.) If you register on either, your login will be in the |
83 |
passwd database, but you will need to login to the other trac (with the same |
84 |
uid/password of course) for the account to be setup therein. |
85 |
|
86 |
If you intend to commit, using the same email for your account, as for your |
87 |
commits is supposed to link the two in the trac-vcs browser. (though that may only |
88 |
work properly in svn, as it doesn't seem to apply to my commit to initialise the |
89 |
repo, which was needed for gitolite to start managing it.) Regardless, your |
90 |
email can be changed after, if it's an issue, though again it applies site-wide. |
91 |
|
92 |
> The scripts in your framework can use functions like |
93 |
> portageq get_repo_path / FROM |
94 |
> or the quicker new |
95 |
> eix-header -p FROM |
96 |
> to find out the corresponding paths, once these repositories |
97 |
> are set up (and in the eix database, respectively). |
98 |
|
99 |
I'd prefer a straightforward, shlex-compatible config file personally. That makes |
100 |
it quick for a sh-based implementation, across the board. It's easy enough to check |
101 |
that {make,layman}.conf haven't changed, and to use the slower setup then. |
102 |
|
103 |
> > Steven J. Long posted: |
104 |
> > > From what you've written, the first thing that springs to mind is |
105 |
> > > /etc/portage/postsync.d/ which has q-reinitialize in it. |
106 |
|
107 |
> > There's also the fact that my patches change dependencies -- that's what |
108 |
> > they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus |
109 |
> > invalidating portage's metadata cache, so if emerge --regen isn't |
110 |
> > triggered afterward, every emerge invocation will take longer. |
111 |
> |
112 |
> For a local overlay you do not need to run emerge --regen. Running |
113 |
> |
114 |
> egencache --repo=kde_unsemantic --update --update-use-local-desc |
115 |
> |
116 |
> after applying the patches is sufficient: If kde_unsemantic has |
117 |
> a higher priority in /etc/portage/repos.conf, its metadata will |
118 |
> be taken. |
119 |
|
120 |
Can we do this in a postsync.d hook, both one that runs eix and one that |
121 |
does not? Pseudo-code of the algorithm you'd use in both cases would be |
122 |
ideal. Well, sh of the top-level would be /ideal/.. ;p |
123 |
|
124 |
> BTW, I would suggest to put into metadata/layout.conf of |
125 |
> [kde-lean;] the lines |
126 |
> |
127 |
> cache-formats = md5-dict |
128 |
> thin-manifests = true |
129 |
> |
130 |
> and if you use git also into .gitignore the line |
131 |
> |
132 |
> /metadata/md5-cache/ |
133 |
> |
134 |
> so that users have to run the above egencache command on their own |
135 |
> (which is better than having possibly outdated checksums for |
136 |
> eclasses in which case md5-cache would not help them, anyway). |
137 |
|
138 |
Lovely, followed to the letter. |
139 |
|
140 |
> >> That's the trouble with glue-scripting: you have to consider the |
141 |
> >> interaction of quite a few disparate commands, and various end-user |
142 |
> >> setups. |
143 |
> |
144 |
> That's why for end-users publishing the patched overlay would |
145 |
> be better: They can still come up with patches anyway, i.e. |
146 |
> they are not even excluded from development if they do not use |
147 |
> your framework. |
148 |
|
149 |
Indeed. |
150 |
|
151 |
Seems apparent we need to get to milestone 0.2 for ebuild-patch |
152 |
before we can think of publishing an overlay. 0.1 is up to Duncan: base |
153 |
just means the initial impl of stage 4, in a state that he's happy for the |
154 |
ROTW to see ;) |
155 |
|
156 |
Regards, |
157 |
steveL. |
158 |
-- |
159 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |