| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 16/09/15 04:30 PM, Rich Freeman wrote: |
| 5 |
> On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny <mgorny@g.o> |
| 6 |
> wrote: |
| 7 |
>> |
| 8 |
>> If you modify an eclass, you're responsible for the outcome. |
| 9 |
>> Even if means revbumping hundreds of ebuilds for the sake of |
| 10 |
>> it. Note that this is the kind of revbump that wouldn't require |
| 11 |
>> resetting stable keywords as long as deps are satisfied. |
| 12 |
> |
| 13 |
> Ok, so it sounds like there are two eclass proposals out there: |
| 14 |
> 1. Modify the eclass in place and then revbump all ebuilds that |
| 15 |
> use it for which the new RDEPEND matters (the second part of this |
| 16 |
> email). 2. Don't modify the eclass in place, and then update the |
| 17 |
> eclass reference and revbump any ebuilds for which the new |
| 18 |
> RDEPEND matters, and for the ones that don't matter there really |
| 19 |
> is no change since they use the old eclass. |
| 20 |
> |
| 21 |
> #1 results in less eclass propagation, but requires mass-commits. |
| 22 |
> #2 seems safer and allows the eclass and ebuilds to be modified |
| 23 |
> separately, but still requires lots of ebuild changing. |
| 24 |
> |
| 25 |
>> |
| 26 |
>> Runtime. The minver can be raised for developer's convenience |
| 27 |
>> -- like when a large number of packages is expected to require |
| 28 |
>> a new version soon, and the developers would otherwise have to |
| 29 |
>> override the eclass- specified versions. Instead, the eclass is |
| 30 |
>> updated and new requirements apply. |
| 31 |
> |
| 32 |
> Does not revbumping in this situation actually save us much other |
| 33 |
> than the need to do the revbumps themselves? |
| 34 |
> |
| 35 |
> If the dependency uses a slot operator then everything is going |
| 36 |
> to get rebuilt anyway as soon as the first package comes along |
| 37 |
> and triggers an update. Then again, it does save us a bunch of |
| 38 |
> revbumps. |
| 39 |
> |
| 40 |
|
| 41 |
..if the minver is bumped on the atom in the eclass, and the package |
| 42 |
is re-emerged without dyndeps, then the existing installed |
| 43 |
dependency is considered fine and kept, whereas with dyndeps it |
| 44 |
would be upgraded. Is that the only thing we need to be concerned |
| 45 |
about? |
| 46 |
|
| 47 |
- - emerge -uD @world would update the dep anyhow |
| 48 |
|
| 49 |
- - emerge -u @world wouldn't rebuild the package if that package |
| 50 |
didn't change, and if the package did change then the new dep would |
| 51 |
get built. |
| 52 |
|
| 53 |
- - emerge [package] is as above. |
| 54 |
|
| 55 |
So I think I can safely drop my concern. Care still needs to be |
| 56 |
given, certainly, as if the in-tree package isn't revbumped and gets |
| 57 |
a patch that only supports the new dep, then suddenly systems will |
| 58 |
fail when said package re-emerges. But that seems bad practice anyhow |
| 59 |
. |
| 60 |
|
| 61 |
|
| 62 |
-----BEGIN PGP SIGNATURE----- |
| 63 |
Version: GnuPG v2 |
| 64 |
|
| 65 |
iF4EAREIAAYFAlX51L8ACgkQAJxUfCtlWe0HYgEAoH7UscWxE4Lgxw+ghFk4EbYY |
| 66 |
xYb5XU02Cg9cqh4kH3UBALJGM5sc9K5mFKEDXkiPJva+U4Txeii0MdD4TJpgEBUM |
| 67 |
=buWM |
| 68 |
-----END PGP SIGNATURE----- |
Archives