On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote: > > Another thing that strikes me is separation of stable vs ~arch behavior. > > This applies in particular with in-place eclass alterations. Users on > ~arch should normally expect more activity (in particular number of > builds and changes, that is after all its definition). Stable users on > the other hand might want slower update cycle for non-security upgrades. > > Reading this thread I got hit with a question whether this boundary is > properly protected if doing in-place eclass changes?
This isn't about whether an eclass used by stable packages are allowed to be modified or not. This is about what has to be done AFTER an eclass is modified, so that users won't run into problems down the road. Today developers are modifying eclass RDEPENDs and not bumping anything. This impacts stable users, but it can do so in ways that cause their systems to break months down the road in ways that are hard to troubleshoot. With the proposal when an eclass is changed the user will get a rebuild, but they won't get the mysterious breakage. I'm not sure that we're doing stable users a favor by not "disturbing" them with rebuilds but instead we're just silently breaking their systems in subtle ways. I think that if anybody would benefit from a more conservative approach it would be the stable users. I'm all for having a separate discussion around when it is and isn't appropriate to modify eclasses that are used by stable packages in the first place. -- Rich
