| 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----- |
Archives