1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 06/04/2012 10:06 PM, Michał Górny wrote: |
5 |
> On Mon, 04 Jun 2012 21:26:00 +0200 hasufell <hasufell@g.o> |
6 |
> wrote: |
7 |
> |
8 |
>> But minetest in sunrise for example which has two different |
9 |
>> repos, one for the engine, one for the data. It's currently split |
10 |
>> in two, but I guess I will merge those soon. |
11 |
> |
12 |
> Why? Is there a good reason to merge two repos into one ebuild? |
13 |
> Does upstream guarantee that the releases will always be synced? |
14 |
> Does it benefit users? |
15 |
|
16 |
In this case yes. They are released with the exact same tags as you |
17 |
can see in those ebuilds. |
18 |
|
19 |
> |
20 |
>> It would also enable me to use gtk-youtube-viewer and |
21 |
>> youtube-viewer in one ebuild with vcs-snapshot eclass while |
22 |
>> adding a gtk useflag (currently split too). Otherwise I will have |
23 |
>> to fix it on my own again. |
24 |
> |
25 |
> Once again: does it benefit user? Or just does it imply that |
26 |
> starting or stopping to use gtk part requires user to rebuild the |
27 |
> whole thing? |
28 |
|
29 |
Eclasses do not benefit any user. They benefit developers. I would |
30 |
simply do similar stuff on my own in the ebuild instead of using |
31 |
vcs-snapshot eclass then. |
32 |
|
33 |
> |
34 |
>> I find the logic very clear: |
35 |
>> |
36 |
>> SRC="https://my/github/shit -> ${P}.tar.gz" results in |
37 |
>> ${WORKDIR}/${P} and SRC="https://my/github/shit -> |
38 |
>> ${P}-src.tar.gz" results in ${WORKDIR}/${P}-src |
39 |
> |
40 |
> I really don't mind the logic. I'm just aware that it is a little |
41 |
> late to introduce such a destructive change, especially that you |
42 |
> yourself mentioned that it will break existing ebuilds. |
43 |
|
44 |
So? We fix it. |
45 |
|
46 |
> |
47 |
> I will be happy to implement it if you can get more approval for |
48 |
> that change. Or else we should consider jumping with the eclass to |
49 |
> -r1 while it isn't widespread too much. |
50 |
> |
51 |
|
52 |
I don't see the point in bumping it, because it's not widespread. |
53 |
-----BEGIN PGP SIGNATURE----- |
54 |
Version: GnuPG v2.0.19 (GNU/Linux) |
55 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
56 |
|
57 |
iQEcBAEBAgAGBQJPzR7lAAoJEFpvPKfnPDWz5W8H/0Je1mE/Vo7X+46TpuZZyi/3 |
58 |
RJaJMYETeQbbhPM6ACIXtHk629fGCz9Oda7J0YG4LMCYTbxU5MNElZSjbV4aThYD |
59 |
MkSoQlSw/RIBuSEaffWRkAtbmNovHzd+nUyK8cHJTYXffi4CmClPXPPTqGAaRbC/ |
60 |
yJf6JBEfMLK/6ps10eMwf7D/m5ZJUYIPJ1m7DmlUqjpr8R8v2bVbjqB//M9ig7KO |
61 |
yl/W5qzlBa2UAw/Gjgi0ITdDKs5sem7J8+PbVZKED5K0sD10YxZKMImCymJSlFkR |
62 |
gzqZi99qdAs8uhZ1K6h8ozkBLglxkT54IZ8Kn3LWwiQ0/I2xRNgX8Ugt1EQnrQM= |
63 |
=X+fU |
64 |
-----END PGP SIGNATURE----- |