| 1 |
On Mon, 5 Aug 2019 09:17:17 -0400, Michael Orlitzky wrote: |
| 2 |
|
| 3 |
> > I've not checked lately, but policy was that if an ebuild change did |
| 4 |
> > not result in differences in the installed files, there was no need |
| 5 |
> > for a version bump. This avoids needless recompiling of packages. |
| 6 |
> > |
| 7 |
> |
| 8 |
> Realistically, almost all ebuild changes should incur a new revision. I |
| 9 |
> would much rather recompile 100 packages *and have it work* than compile |
| 10 |
> 10 packages and have it crash three times requiring manual intervention |
| 11 |
> because the tree is so screwed up. |
| 12 |
> |
| 13 |
> We have better guidelines these days: |
| 14 |
> |
| 15 |
> https://devmanual.gentoo.org/general-concepts/ebuild-revisions |
| 16 |
> |
| 17 |
> but they still give developers too much freedom to be lazy and commit |
| 18 |
> important changes without a revision. The "straight to stable" advice |
| 19 |
> contradicts our existing stabilization policy, and the USE flag advice |
| 20 |
> says that you can rely on a non-default, portage-only feature to prevent |
| 21 |
> breakage. |
| 22 |
|
| 23 |
That's pretty much how I remember it. If the existing version crash, then |
| 24 |
the binaries have changed so it should be bumped, but if a dev missed out |
| 25 |
a new DEPEND for chromium of libreoffice that I happen to have already |
| 26 |
installed, I don't want to have to waste hours of CPU time recompiling to |
| 27 |
exactly the same end point. |
| 28 |
|
| 29 |
The most important statement in the policy is also the hardest to enforce |
| 30 |
"Developers are encouraged to use common sense" :-O |
| 31 |
|
| 32 |
|
| 33 |
-- |
| 34 |
Neil Bothwick |
| 35 |
|
| 36 |
What is a "free" gift ? Aren't all gifts free? |
Archives