| 1 |
Oh yeah, as Neil was pointing that out. |
| 2 |
|
| 3 |
I will give it a try and report soon. |
| 4 |
|
| 5 |
-Ramon |
| 6 |
|
| 7 |
On 28/07/2020 14:52, tastytea wrote: |
| 8 |
> On 2020-07-28 12:02+0200 Ramon Fischer <Ramon_Fischer@×××××××.de> wrote: |
| 9 |
> |
| 10 |
>> Hello tastytea, |
| 11 |
>> |
| 12 |
>> I am aware of this "workaround", thank you. :) |
| 13 |
>> |
| 14 |
>> I guess, I was not precise enough: |
| 15 |
>> |
| 16 |
>> The ebuild "drm_master_util-9999"[1] is hosted on my repository, but |
| 17 |
>> the ebuild file itself pulls in an external repository[2]. |
| 18 |
> Sorry, I misread your first email. |
| 19 |
> |
| 20 |
>> My question is: Is it a best practise to fork the external |
| 21 |
>> repository[2], to link my fork with "drm_master_util-9999"[1], so I |
| 22 |
>> have full control about updating the fork. Just to check, that the |
| 23 |
>> external source is not doing shenanigans? |
| 24 |
> I would use either EGIT_COMMIT from git-r3.eclass¹ or download a |
| 25 |
> snapshot via SRC_URI². |
| 26 |
> |
| 27 |
> ¹ <https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html#lbAF> |
| 28 |
> ² <https://github.com/gch1p/drm_master_util/archive/<COMMIT-HASH>.tar.gz> |
| 29 |
> |
Archives