| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 09/06/14 12:31 PM, Micha³ Górny wrote: |
| 5 |
> Dnia 2014-06-09, o godz. 18:23:21 Ulrich Mueller <ulm@g.o> |
| 6 |
> napisa³(a): |
| 7 |
> |
| 8 |
>>>>>>> On Mon, 09 Jun 2014, Jonathan Callen wrote: |
| 9 |
>> |
| 10 |
>>> Just as a thought, perhaps we might add another phase, named |
| 11 |
>>> like "src_postpatch" (open to bikesheding), and have the |
| 12 |
>>> `eapply_user` called automatically between src_prepare and |
| 13 |
>>> src_postpatch. Any post-user patch code (like eautoreconf) |
| 14 |
>>> would then go in src_postpatch. |
| 15 |
>> |
| 16 |
>>> Thoughts? |
| 17 |
>> |
| 18 |
>> As I said before, I believe that the package manager shouldn't |
| 19 |
>> perform any magic operations between src_* phases. Calling |
| 20 |
>> eapply_user like this is effectively an additional phase, so it's |
| 21 |
>> conceptually cleaner to make it a regular phase function (e.g., |
| 22 |
>> src_userpatch) which would be called between src_prepare and |
| 23 |
>> src_postpatch. |
| 24 |
> |
| 25 |
> Sounds insanely complex for a minor issue. What's the problem with |
| 26 |
> ebuilds calling 'default' in src_prepare() to get user patches |
| 27 |
> applied (and possibly ${PATCHES[@]} as well)? |
| 28 |
> |
| 29 |
|
| 30 |
Again, it's a bit of a special case this it's just 'one' build system, |
| 31 |
but, what if either a user's patch changes configure.ac , but the |
| 32 |
ebuild itself hasn't patched configure.ac and so doesn't eautoreconf |
| 33 |
(or for that matter, doesn't even inherit autotools). |
| 34 |
|
| 35 |
The 'default' src_prepare would need to be smart enough to know that |
| 36 |
the patch is changing build system bits, and either trigger the |
| 37 |
appropriate prepare commands (eautoreconf or similar) or at least |
| 38 |
EQAWARN that the patch applied but won't take effect. And technically |
| 39 |
that eqawarn should only occur if there is no eautoreconf coming up in |
| 40 |
src_prepare (which could very well happen -after- 'default').. |
| 41 |
|
| 42 |
- ----- |
| 43 |
|
| 44 |
I read earlier that the proposal is saying that src_prepare() needs to |
| 45 |
be implemented for every package; it may make sense to include |
| 46 |
eclass-inherited implementations in this too, since I expect it would |
| 47 |
be more palatable to i.e. force inherit autotools-utils than to force |
| 48 |
a handwritten, previously-unneeded src_prepare |
| 49 |
|
| 50 |
|
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 53 |
|
| 54 |
iF4EAREIAAYFAlOV5DQACgkQ2ugaI38ACPD1mAD/StbF40970Sorj2nr9SvBTqwf |
| 55 |
rnl4spmgkTr26EECMMMA/ijDZEviIJfgUv2j7aeC5mhwAmMIKWz+NnBpQlMZ1jxf |
| 56 |
=7/2K |
| 57 |
-----END PGP SIGNATURE----- |
Archives