| 1 |
On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> If you modify an eclass, you're responsible for the outcome. Even if |
| 4 |
> means revbumping hundreds of ebuilds for the sake of it. Note that this |
| 5 |
> is the kind of revbump that wouldn't require resetting stable keywords |
| 6 |
> as long as deps are satisfied. |
| 7 |
|
| 8 |
Ok, so it sounds like there are two eclass proposals out there: |
| 9 |
1. Modify the eclass in place and then revbump all ebuilds that use |
| 10 |
it for which the new RDEPEND matters (the second part of this email). |
| 11 |
2. Don't modify the eclass in place, and then update the eclass |
| 12 |
reference and revbump any ebuilds for which the new RDEPEND matters, |
| 13 |
and for the ones that don't matter there really is no change since |
| 14 |
they use the old eclass. |
| 15 |
|
| 16 |
#1 results in less eclass propagation, but requires mass-commits. #2 |
| 17 |
seems safer and allows the eclass and ebuilds to be modified |
| 18 |
separately, but still requires lots of ebuild changing. |
| 19 |
|
| 20 |
> |
| 21 |
> Runtime. The minver can be raised for developer's convenience -- like |
| 22 |
> when a large number of packages is expected to require a new version |
| 23 |
> soon, and the developers would otherwise have to override the eclass- |
| 24 |
> specified versions. Instead, the eclass is updated and new requirements |
| 25 |
> apply. |
| 26 |
|
| 27 |
Does not revbumping in this situation actually save us much other than |
| 28 |
the need to do the revbumps themselves? |
| 29 |
|
| 30 |
If the dependency uses a slot operator then everything is going to get |
| 31 |
rebuilt anyway as soon as the first package comes along and triggers |
| 32 |
an update. Then again, it does save us a bunch of revbumps. |
| 33 |
|
| 34 |
-- |
| 35 |
Rich |
Archives