-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/09/15 04:30 PM, Rich Freeman wrote: > On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny <mgo...@gentoo.org> > wrote: >> >> If you modify an eclass, you're responsible for the outcome. >> Even if means revbumping hundreds of ebuilds for the sake of >> it. Note that this is the kind of revbump that wouldn't require >> resetting stable keywords as long as deps are satisfied. > > Ok, so it sounds like there are two eclass proposals out there: > 1. Modify the eclass in place and then revbump all ebuilds that > use it for which the new RDEPEND matters (the second part of this > email). 2. Don't modify the eclass in place, and then update the > eclass reference and revbump any ebuilds for which the new > RDEPEND matters, and for the ones that don't matter there really > is no change since they use the old eclass. > > #1 results in less eclass propagation, but requires mass-commits. > #2 seems safer and allows the eclass and ebuilds to be modified > separately, but still requires lots of ebuild changing. > >> >> Runtime. The minver can be raised for developer's convenience >> -- like when a large number of packages is expected to require >> a new version soon, and the developers would otherwise have to >> override the eclass- specified versions. Instead, the eclass is >> updated and new requirements apply. > > Does not revbumping in this situation actually save us much other > than the need to do the revbumps themselves? > > If the dependency uses a slot operator then everything is going > to get rebuilt anyway as soon as the first package comes along > and triggers an update. Then again, it does save us a bunch of > revbumps. >
..if the minver is bumped on the atom in the eclass, and the package is re-emerged without dyndeps, then the existing installed dependency is considered fine and kept, whereas with dyndeps it would be upgraded. Is that the only thing we need to be concerned about? - - emerge -uD @world would update the dep anyhow - - emerge -u @world wouldn't rebuild the package if that package didn't change, and if the package did change then the new dep would get built. - - emerge [package] is as above. So I think I can safely drop my concern. Care still needs to be given, certainly, as if the in-tree package isn't revbumped and gets a patch that only supports the new dep, then suddenly systems will fail when said package re-emerges. But that seems bad practice anyhow . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlX51L8ACgkQAJxUfCtlWe0HYgEAoH7UscWxE4Lgxw+ghFk4EbYY xYb5XU02Cg9cqh4kH3UBALJGM5sc9K5mFKEDXkiPJva+U4Txeii0MdD4TJpgEBUM =buWM -----END PGP SIGNATURE-----
