1 |
On Mon, 04 Jun 2012 21:26:00 +0200 |
2 |
hasufell <hasufell@g.o> wrote: |
3 |
|
4 |
> But minetest in sunrise for example which has two different repos, one |
5 |
> for the engine, one for the data. It's currently split in two, but I |
6 |
> guess I will merge those soon. |
7 |
|
8 |
Why? Is there a good reason to merge two repos into one ebuild? Does |
9 |
upstream guarantee that the releases will always be synced? Does it |
10 |
benefit users? |
11 |
|
12 |
> Lately there was an ebuild proposal in sunrise too which had that |
13 |
> issue, see here https://gist.github.com/2829184 |
14 |
|
15 |
That's a more likely case. But still such a change would involve |
16 |
changing an established API heavily which I really dislike. |
17 |
|
18 |
> It would also enable me to use gtk-youtube-viewer and youtube-viewer |
19 |
> in one ebuild with vcs-snapshot eclass while adding a gtk useflag |
20 |
> (currently split too). |
21 |
> Otherwise I will have to fix it on my own again. |
22 |
|
23 |
Once again: does it benefit user? Or just does it imply that starting |
24 |
or stopping to use gtk part requires user to rebuild the whole thing? |
25 |
|
26 |
> I find the logic very clear: |
27 |
> |
28 |
> SRC="https://my/github/shit -> ${P}.tar.gz" |
29 |
> results in ${WORKDIR}/${P} |
30 |
> and |
31 |
> SRC="https://my/github/shit -> ${P}-src.tar.gz" |
32 |
> results in ${WORKDIR}/${P}-src |
33 |
|
34 |
I really don't mind the logic. I'm just aware that it is a little late |
35 |
to introduce such a destructive change, especially that you yourself |
36 |
mentioned that it will break existing ebuilds. |
37 |
|
38 |
I will be happy to implement it if you can get more approval for that |
39 |
change. Or else we should consider jumping with the eclass to -r1 while |
40 |
it isn't widespread too much. |
41 |
|
42 |
-- |
43 |
Best regards, |
44 |
Michał Górny |