[gentoo-dev] Dynamic dependencies

[gentoo-dev] Dynamic dependencies

[Andreas K. Huettel]

Hi all, 

here's a quote from the Council 20140826 summary:

> Dynamic dependencies in Portage
> ===============================
> During discussion, is was remarked that some changes, e.g. to
> dependencies in eclasses, could require mass rebuilds of packages.
> 
> Vote:
> - "The council asks the Portage team to first outline their long-term
>   plan regarding removal or replacement of dynamic dependencies,
>   before they remove this feature. In particular, tree policies and
>   the handling of eclasses and virtuals need to be clarified."
>   Accepted unanimously.

Since there seems to be interest in the Portage team to go ahead with that 
plan, I'd like to ask about the tree policies and the handling of eclasses and 
virtuals.

I guess we'd appreciate this as a prerequisite for being able to give the plan 
future council support.

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer
perl, office, comrel, council

Re: [gentoo-dev] Dynamic dependencies

[hasufell]

On 09/16/2015 05:49 PM, Andreas K. Huettel wrote:
> Hi all, 
> 
> here's a quote from the Council 20140826 summary:
> 
>> Dynamic dependencies in Portage
>> ===============================
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>>   plan regarding removal or replacement of dynamic dependencies,
>>   before they remove this feature. In particular, tree policies and
>>   the handling of eclasses and virtuals need to be clarified."
>>   Accepted unanimously.
> 
> Since there seems to be interest in the Portage team to go ahead with that 
> plan, I'd like to ask about the tree policies and the handling of eclasses and 
> virtuals.
> 
> I guess we'd appreciate this as a prerequisite for being able to give the plan 
> future council support.
> 

I'm against it, because I would...
* not be able to depend on portage specific behavior anymore
* not be able to break the dep-graph for portage users who disable
dynamic dependencies (and even those who don't)
* not be able to break the dep-graph for paludis users
* be forced to actually write ebuilds that comply to PMS
* have to care about correctness of dependencies
* have to do some work, actually
* have to listen to people like PMS and PM authors, but I am smarter

Instead we should...
* start another thread of ~100 mails where PM authors have to repeatedly
explain the problem to every single developer
* let the council dictate over 3-liner devmanual patches that are merely
expressions of the current PMS standard
* piss off everyone who was even remotely thinking of working on this
(there's no one anymore, so maybe this point can be omitted)

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 11:49 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Hi all,
>
> here's a quote from the Council 20140826 summary:
>
>> Dynamic dependencies in Portage
>> ===============================
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>>   plan regarding removal or replacement of dynamic dependencies,
>>   before they remove this feature. In particular, tree policies and
>>   the handling of eclasses and virtuals need to be clarified."
>>   Accepted unanimously.
>
> Since there seems to be interest in the Portage team to go ahead with that
> plan, I'd like to ask about the tree policies and the handling of eclasses and
> virtuals.

I'll go ahead and start a tangent on this thread right here.  As a
first step can we separately consider the proposal to require a
revbump anytime a package's RDEPENDS changes?  I'm referring here to
directly-specified RDEPENDS, not those inherited from an eclass or
virtual.

I agree completely that we need to solve the eclass and virtual issue
and that is by far the stickier part of the mess.  However, can we at
least get ebuild authors to stop making changes to their RDEPENDS
without revbumps?  If nothing else that will hopefully provide some
immediate relief to users with dependency breakage, and it doesn't
entail the amount of mass-rebuilding you can potentially get with the
eclass and virtual side of the problem.

And I acknowledge that this is not my original idea...

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/16/2015 09:21 AM, hasufell wrote:
> On 09/16/2015 05:49 PM, Andreas K. Huettel wrote:
>> Hi all,
>> 
>> here's a quote from the Council 20140826 summary:
>> 
>>> Dynamic dependencies in Portage 
>>> =============================== During discussion, is was
>>> remarked that some changes, e.g. to dependencies in eclasses,
>>> could require mass rebuilds of packages.
>>> 
>>> Vote: - "The council asks the Portage team to first outline
>>> their long-term plan regarding removal or replacement of
>>> dynamic dependencies, before they remove this feature. In
>>> particular, tree policies and the handling of eclasses and
>>> virtuals need to be clarified." Accepted unanimously.
>> 
>> Since there seems to be interest in the Portage team to go ahead
>> with that plan, I'd like to ask about the tree policies and the
>> handling of eclasses and virtuals.
>> 
>> I guess we'd appreciate this as a prerequisite for being able to
>> give the plan future council support.
>> 
> 
> I'm against it, because I would... * not be able to depend on
> portage specific behavior anymore * not be able to break the
> dep-graph for portage users who disable dynamic dependencies (and
> even those who don't) * not be able to break the dep-graph for
> paludis users * be forced to actually write ebuilds that comply to
> PMS * have to care about correctness of dependencies * have to do
> some work, actually * have to listen to people like PMS and PM
> authors, but I am smarter
> 
> Instead we should... * start another thread of ~100 mails where PM
> authors have to repeatedly explain the problem to every single
> developer * let the council dictate over 3-liner devmanual patches
> that are merely expressions of the current PMS standard * piss off
> everyone who was even remotely thinking of working on this (there's
> no one anymore, so maybe this point can be omitted)
> 

As a developer interested in adhering to the PMS, do we have a tool to
check conformance beyond repoman? How would virtuals be handled with
static dependencies?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV+bErAAoJEAEkDpRQOeFwaM0QANan7U4hgyJk7GLhHriWerFP
fisJ2yeBeXyzSu9N9XnGAcGKZcanYjvbZs/gLUwbwdGcFXgkxYYcHceh8k+6ZvlH
LPpKy7j+0Af7l0Ooe1wToJ52pyeZZR0N1rKNYPWuY21i9mTHjXYmlX/m7gpAEkPP
WBv/9JiJm9wLJ6rY66fjsBRU/FEyDumI+qv4/FLiIkKmquHDtYCgnryx/ERAXcoW
XpA58zBa0FBQESNaQ1NbDutTJNPZpgtkCTwtMzZ8puO1EGggOrq9yKV6EROztA36
JfzJY4uAQjsaN/AKnULeAeoXBIstFmMvD3b+aeJCTFWLCPz1GVNcVunPjaRwMLCH
MmwzbNMKf+JiBfTxgjWV0NSG3SMosv/e5B72BlvEW+wSTim6O6suSXcLtbkRrAqW
kO/sBo1OqCvolBuvfnngS1/fqSloJjwyimp5utLdDrW212OS3kxaQSDCxeXfJce1
+5mXBSgCEzkBgb0oaZj6BQEcMjFXT9cq+Aa8yUTpPDXpB1el5ogTcWHBt8sQNZjV
V1k0nfIBJqJMydFxsrE7GzaRxqwkptu6mn6A/6rt6mKUJtwWDMKdPKm9cmDa0Vrl
al5moOiDJ1lS07AxPD6q2yjSjn/v3FZC7gh91HM0p+6xK90ttH9oHB3yivfE2DLL
gKkJbCq9/tYV7li8hE7Q
=83M7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/09/15 02:13 PM, Daniel Campbell wrote:
> How would virtuals be handled with static dependencies?

AFAIK virtuals would need to be handled the same as anything else --
when updating an atom in RDEPEND, the virtual's ebuild needs to be
revbumped.  This would mean that on --update --deep, the new virtual
would get emerged and so the VDB would be updated again with the
proper list of atom(s) that satisfy it.

Same would have to go for eclasses that include dependencies -- any
time an atom changes, the eclass needs to be revbumped and anything
inheriting it also needs to be revbumped (and its inherit line
adjusted).  Of course we may need some well-defined guidelines (if
we don't have them already) on when and how we can remove the old
eclasses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlX5vjcACgkQAJxUfCtlWe2UiQD/V+w5t64RkYsqFMqYZevlmVH4
01NkXPI0b9NmM4+chSEBANl2HL+KryM5avwa4EDTYbSA11W4IeTVc+lww9MJXn+V
=RZgQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

Dnia 2015-09-16, o godz. 17:49:24
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Hi all, 
> 
> here's a quote from the Council 20140826 summary:
> 
> > Dynamic dependencies in Portage
> > ===============================
> > During discussion, is was remarked that some changes, e.g. to
> > dependencies in eclasses, could require mass rebuilds of packages.
> > 
> > Vote:
> > - "The council asks the Portage team to first outline their long-term
> >   plan regarding removal or replacement of dynamic dependencies,
> >   before they remove this feature. In particular, tree policies and
> >   the handling of eclasses and virtuals need to be clarified."
> >   Accepted unanimously.
> 
> Since there seems to be interest in the Portage team to go ahead with that 
> plan, I'd like to ask about the tree policies and the handling of eclasses and 
> virtuals.
> 
> I guess we'd appreciate this as a prerequisite for being able to give the plan 
> future council support.

How about the usual 'common sense' policy? Assuming the developer
understands the consequences of bumping and not bumping, and can see
for himself if the latter breaks stuff (which would happen once portage
finally changes the default behavior and makes failures non-random).

As for virtuals and eclasses, I don't really understand why anyone
thinks they are special in any regard. In both cases, we're talking
about regular dependency change in metadata, and we need to understand
the consequences. And they're going to be the same whether we change
dep A to B, A to virtual, and whether we change it directly or via
eclass.

Long story short:

1. Build-time dependency changes don't need revbump unless they
resulted in broken built package. Pretty much like any other build-time
fix.

2. Dependency changes that don't need to apply immediately don't need
revbump. For example, if foo.eclass raises minimal required version of
a dependency but all packages built so far will work with the old one.

3. For non-important fixes, a revbump is recommended. Like when
the package rarely breaks due to missing dep, or the dependency is
implicitly pulled in but should be listed explicitly for completeness.

4. For any change that could result in conflicts or major problems for
people who are stuck with old metadata, revbump is required. This for
example applies to the Perl team virtuals which frequently make
updating impossible.

There are probably more common cases to be considered but that's
the ones that immediately come to my mind.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> As for virtuals and eclasses, I don't really understand why anyone
> thinks they are special in any regard. In both cases, we're talking
> about regular dependency change in metadata, and we need to understand
> the consequences. And they're going to be the same whether we change
> dep A to B, A to virtual, and whether we change it directly or via
> eclass.

Sure, but a developer KNOWS when their RDEPENDS change when they're
modifying it directly in an ebuild.  If they inherit an eclass and it
sets an RDEPEND and the eclass changes, then it effectively changes
the dependency for every ebuild that inherits it even though there
weren't any commits to any of those ebuilds.

So, we need to think about what kinds of changes we allow to eclasses.
This also applies to virtuals, but those don't have the same kind of
indirect impact to packages that RDEPEND on them any more than changes
in any other RDEPEND of an RDEPEND.

> 2. Dependency changes that don't need to apply immediately don't need
> revbump. For example, if foo.eclass raises minimal required version of
> a dependency but all packages built so far will work with the old one.
>

Are we talking about a build dependency or a run-time dependency?  I
don't get why we'd increase the minimal required version of a run-time
dependency if everything built so far still works with the old
version.

Also, assuming that there is a case where this actually happens, does
this have any impact on running --depclean or any other obscure
blocker issues because the version in VDB is no longer in the tree?

When the policy is just a simple "always revbump when you change
RDEPEND, whether you're an ebuild, an eclass, or a virtual" then I can
see how it is painful, but I can also see how it is fairly
bulletproof.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

On Wed, 16 Sep 2015 21:31:04 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Assuming the developer understands the consequences of bumping and
> not bumping

Well that narrows it down to about three people, and only if they're
thinking very very carefully.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/09/15 03:49 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny
> <mgorny@gentoo.org> wrote:
>> 2. Dependency changes that don't need to apply immediately 
>> don't need revbump. For example, if foo.eclass raises minimal 
>> required version of a dependency but all packages built so far 
>> will work with the old one.
>> 
> 
> Are we talking about a build dependency or a run-time
> dependency? I don't get why we'd increase the minimal required
> version of a run-time dependency if everything built so far still
> works with the old version.

I'm also concerned with this one.  Bumping version in an eclass so
that the minver that everything -in the tree- needs is correct seems
to me could suddenly make incorrect everything that's currently
emerged up to that change.

That said this might not matter since deps are almost always pushed
up to latest stable/~arch anyways, so perhaps i'm just generally
being more sensitive on this than is necessary.  Definitely, if the
minver was bumped to fix a bug, then imo the eclass needs bumping to
enforce the vdb update.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlX5yR4ACgkQAJxUfCtlWe3BZQD8CPVQ/oEjszqAFtgQzLFKKOSz
3fXRt3ARQE8HHI/jyTwA/jMOnDTTENLs7R/8r2VYYrHIUAv6mrQljuSU2zalJEXY
=S25f
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Dnia 2015-09-16, o godz. 15:49:24
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >
> > As for virtuals and eclasses, I don't really understand why anyone
> > thinks they are special in any regard. In both cases, we're talking
> > about regular dependency change in metadata, and we need to understand
> > the consequences. And they're going to be the same whether we change
> > dep A to B, A to virtual, and whether we change it directly or via
> > eclass.
> 
> Sure, but a developer KNOWS when their RDEPENDS change when they're
> modifying it directly in an ebuild.  If they inherit an eclass and it
> sets an RDEPEND and the eclass changes, then it effectively changes
> the dependency for every ebuild that inherits it even though there
> weren't any commits to any of those ebuilds.

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.

> > 2. Dependency changes that don't need to apply immediately don't need
> > revbump. For example, if foo.eclass raises minimal required version of
> > a dependency but all packages built so far will work with the old one.
> >
> 
> Are we talking about a build dependency or a run-time dependency?  I
> don't get why we'd increase the minimal required version of a run-time
> dependency if everything built so far still works with the old
> version.

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.

> Also, assuming that there is a case where this actually happens, does
> this have any impact on running --depclean or any other obscure
> blocker issues because the version in VDB is no longer in the tree?

It shouldn't have. And if it would, the issues with the whole 'do
stupid stuff and not bump' policy would be much worse.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny <mgorny@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.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----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 <mgorny@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-----

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 4:44 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> - - 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.

Just to be clear, my point was that if the reason the eclass was
updated was because some new package version in the tree needed it,
and you update that other package in the tree, then that will update
the dependency, and that would in turn rebuild anything with a slot
operator dep on it.

Which is of course exactly what should happen if the soname/ABI needs to change.

>
> 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
> .

Right, a patch change would always require a revbump and that is
nothing new.  The only case that doesn't require a revbump is a
build-time change.  And if somebody makes a build-time change with the
assumption that the new minimum depencency version is in effect it is
fine, since anybody with it already installed won't be rebuilding it,
and if anybody does rebuild it then portage will check and force the
dependency update so everything is fine at build time.

So, assuming we want to entertain the "only revbump if necessary"
eclass wording, do we think we can actually come up with something
that not only makes technical sense, but where we can actually expect
developers to get it right 99% of the time?  Are we encouraging
dangerous behavior just because a few of us might or might not be able
to get it right?

I suppose if somebody does mess up we can go in and revbump a bunch of
ebuilds.  The thing is that such problems are very hard to detect -
they usually manifest as users posting bizarre portage output on lists
and forums and being showered with a lot of bad advice before somebody
who knows what they're talking about notices the thread, and it can
happen a while after the commit that introduced the problem.

So, part of me really wonders if it is worth it just to save a bunch
of revbumps that probably could be done by a script and with git it
can even happen atomically and with the possibility of review or
testing.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Alexis Ballier]

On Wed, 16 Sep 2015 21:31:04 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2015-09-16, o godz. 17:49:24
> "Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):
> 
> > Hi all, 
> > 
> > here's a quote from the Council 20140826 summary:
> > 
> > > Dynamic dependencies in Portage
> > > ===============================
> > > During discussion, is was remarked that some changes, e.g. to
> > > dependencies in eclasses, could require mass rebuilds of packages.
> > > 
> > > Vote:
> > > - "The council asks the Portage team to first outline their
> > > long-term plan regarding removal or replacement of dynamic
> > > dependencies, before they remove this feature. In particular,
> > > tree policies and the handling of eclasses and virtuals need to
> > > be clarified." Accepted unanimously.
> > 
> > Since there seems to be interest in the Portage team to go ahead
> > with that plan, I'd like to ask about the tree policies and the
> > handling of eclasses and virtuals.
> > 
> > I guess we'd appreciate this as a prerequisite for being able to
> > give the plan future council support.
> 
> How about the usual 'common sense' policy? Assuming the developer
> understands the consequences of bumping and not bumping, and can see
> for himself if the latter breaks stuff (which would happen once
> portage finally changes the default behavior and makes failures
> non-random).

+1000

Moreover, as you said, it is included in the good old policy, which is
even a quizz question iirc:

1.	You change a package's ebuild to install an init script.
	Previously, the package had no init script at all.
	Is a revision bump necessary? Why? What about when adding a
	patch?



For virtuals, they are simply packages that install only VDB entries, so
the above applies too.
For eclasses, I think we all agree that it is better to store them in
VDB too (otherwise we can't remove them, ever), so again the above
applies.


Alexis.

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/16/2015 07:09 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 11:49 AM, Andreas K. Huettel 
> <dilfridge@gentoo.org> wrote:
>> Hi all,

..

> 
> I'll go ahead and start a tangent on this thread right here.  As a 
> first step can we separately consider the proposal to require a 
> revbump anytime a package's RDEPENDS changes?  I'm referring here
> to directly-specified RDEPENDS, not those inherited from an eclass
> or virtual.
> 
> I agree completely that we need to solve the eclass and virtual
> issue and that is by far the stickier part of the mess.  However,
> can we at least get ebuild authors to stop making changes to their
> RDEPENDS without revbumps?

That would certainly be a step in the right direction

fwiw, I've been running for quite a while with dynamic deps disabled
on a few of my computers for quite some time, specifically the
workstations (desktop/laptop), and the sun hasn't dropped out of the
sky yet.


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJV+qdvAAoJECULev7WN52FfBEIAIuONm0m+pxG2q+5ATlY2jgj
GI9mVVi0R2AF8/9zqnBYmVAUaK7Hizn/yMBRkMasJt/J3SiQkuVwnnynwY8mIjOf
hHFAd205asghcvZsNLl4idiVxN6BsJYTFOgVjLfTYwqyNIESsrlyNULz8UZGZsDr
6X/pdX7LZSW3gkPMN/rrasOvHyu/hQ2Pp75WK8YxmJwqxIlAxSWuO4Znjf1Sl2n8
qfwaAK5XXTEUG+h+sP8OGNhGsb9Tm+pFGmlJ4LpiiN2DPkg0i4oXK4Wec7U5Aana
GaggPYGeH3XWld47ZhV2pXyyw8nGDz7R7rXCVFoSmC9a1sEvRH4jHQXRUgagmwI=
=wxzt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/17/2015 12:27 AM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 4:44 PM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> 

..

> 
> So, part of me really wonders if it is worth it just to save a
> bunch of revbumps that probably could be done by a script and with
> git it can even happen atomically and with the possibility of
> review or testing.
> 

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?


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJV+qq0AAoJECULev7WN52FkUIH/2P2tqTNf5YAU7VnB4Mx/glv
Ccqu/rlS+bJsBpJJRombIUwYnKOu+f9Fl49VCsOGVxmulKRR0lciTA4VKGo4XLQb
zk0DGudcPNIvUPuVUojDhzhS9RHoVZuwwZmn4SG6gX7XoFB5fkYYTNE7pt0YCmao
oP4Ku/6df4Y574BHUo01AXlipWnr7HLfIxKTifXXbDhW6O5z9WYfMOd7bHysJz8W
Rk+QzIkDkpSC7hcofVtM24gAH/BYHe67rV2bMJsVyeoseuzT2PY9rZdFdvVqJWU8
mSLdEqOdCC+bShtIeSMYV+r0ZsbrskPONvdILadi+Be5bkNSHh7UIDPZXVbanD4=
=5p9L
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Markos Chandras]

On 09/16/2015 04:49 PM, Andreas K. Huettel wrote:
> Hi all, 
> 
> here's a quote from the Council 20140826 summary:
> 
>> Dynamic dependencies in Portage
>> ===============================
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>>   plan regarding removal or replacement of dynamic dependencies,
>>   before they remove this feature. In particular, tree policies and
>>   the handling of eclasses and virtuals need to be clarified."
>>   Accepted unanimously.
> 
> Since there seems to be interest in the Portage team to go ahead with that 
> plan, I'd like to ask about the tree policies and the handling of eclasses and 
> virtuals.
> 
> I guess we'd appreciate this as a prerequisite for being able to give the plan 
> future council support.
> 
> Cheers, 
> Andreas
> 

could someone explain what the dynamic dependencies are in the context
of portage and ebuilds? because that does seem to be something
portage-internal specific in the way it handles changes in {,R}DEPEND
without revbumps. Where is this thing documented in the first place?

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] Dynamic dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Thu, 17 Sep 2015 20:14:59 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:
> could someone explain what the dynamic dependencies are in the context
> of portage and ebuilds? because that does seem to be something
> portage-internal specific in the way it handles changes in {,R}DEPEND
> without revbumps. Where is this thing documented in the first place?

Sometimes, Portage will sort of use the dependencies specified in an
ebuild rather than the dependencies specified in VDB for certain
operations under certain conditions and certain phases of the moon,
except when it doesn't. This is a quirk left over from the olden days,
when Portage could only handle the existence of one version of any given
package, and so couldn't cope with there being something called foo-1.2
in VDB and something else called foo-1.2 in the tree. This bug was
largely fixed when env saving meant that eclasses no longer had to
remain compatible with things in VDB, but traces of it still remain to
cause confusion.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-dev] Re: Dynamic dependencies

[Duncan]

Kristian Fiskerstrand posted on Thu, 17 Sep 2015 13:43:47 +0200 as
excerpted:

> fwiw, I've been running for quite a while with dynamic deps disabled on
> a few of my computers for quite some time, specifically the workstations
> (desktop/laptop), and the sun hasn't dropped out of the sky yet.

Same here, except that I'm also running...

--changed-deps (and I've long run --newuse)

..., as it seems to avoid many of the blockers I otherwise had, too many 
of which often required convoluted manual resolution that was simply a 
pain for me, but likely insurmountable without help for many others.

Tho a word of caution, --changed-deps defaults to --selective as well, 
which messed with my emerge scriptlets until I added --selective=y/n as 
appropriate to each.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Dynamic dependencies

[Duncan]

Ciaran McCreesh posted on Thu, 17 Sep 2015 20:31:36 +0100 as excerpted:

> On Thu, 17 Sep 2015 20:14:59 +0100 Markos Chandras <hwoarang@gentoo.org>
> wrote:
>> could someone explain what the dynamic dependencies are in the context
>> of portage and ebuilds? because that does seem to be something
>> portage-internal specific in the way it handles changes in {,R}DEPEND
>> without revbumps. Where is this thing documented in the first place?
> 
> Sometimes, Portage will sort of use the dependencies specified in an
> ebuild rather than the dependencies specified in VDB for certain
> operations under certain conditions and certain phases of the moon,
> except when it doesn't. This is a quirk left over from the olden days,
> when Portage could only handle the existence of one version of any given
> package, and so couldn't cope with there being something called foo-1.2
> in VDB and something else called foo-1.2 in the tree. This bug was
> largely fixed when env saving meant that eclasses no longer had to
> remain compatible with things in VDB, but traces of it still remain to
> cause confusion.

[There's discussion of a potential news item below.  People familiar with 
the dynamic-deps discussion in general may wish to skip to it.  See under 
the "Possible News item?" heading.]

Additionally, AFAIK, portage entirely disables dynamic-deps and uses 
static deps any time subslots are used.  Until the introduction of sub-
slots, portage did enough dynamic-dep calculation that devs could and did 
normally assume it, creating problems for static-dep PMs and the 
occasions when portage switched to static-deps.  Static vs. dynamic deps 
assumption still causes problems, but because subslots disable dynamic-
deps and they are now relatively common, static-deps have gradually 
become the general experience, and assumption of dynamic-deps has 
gradually become more of a problem than assumption of static-deps, the 
problem being that the cases in which one can avoid revbumping are 
slightly different with each, in ways that not everybody finds easy to 
understand, let alone keep in mind every time they write or change a dep.

So at some point, the portage devs proposed switching everything over to 
static deps, simplifying things for everyone and allowing them to drop 
the dynamic-deps code.  But back when it was originally proposed, subslots 
were new and not yet widely used, and people used to the old dynamic-deps 
way protested.  (And FWIW, certain political histories definitely didn't 
help.)

So council was called in, and it asked the portage folks to take some 
steps that, portage development being what it is, had the effect of 
slowing down and delaying things for long enough that, hopefully, people 
have had time to come to terms with the changes, and with a bit of 
familiarity, see static-deps aren't so bad, after all.

So now that subslots, and with them, static-dep handling, have become 
more common, hopefully people will see the benefits of getting rid of 
dynamic-deps entirely, thus simplifying things for both the portage devs 
and gentoo package maintainers in general, since there won't be two 
rather similar but annoyingly different in small details sets of deps-
resolution and corresponding revbump rules, to keep track of.

The one big remaining technical sub-problem to resolve is eclasses that 
specify rdeps, since with static deps, changes there can have pretty huge 
effects, potentially forcing many rebuilds.  (Personally, I don't see the 
virtuals thing as so much of an issue, since at worst, their effect tends 
to be rebuild of the single package filling the virtual, basically the 
same effect it has at the ebuild level.  Eclasses, OTOH...)  But that 
seems to be being worked thru in this thread, and a reasonable conclusion 
seems within reach. =:^)


Possible News item?

Beyond that, there's one other issue nagging at me, that I've not yet 
seen discussed, likely because it would have been premature, previously.

What's the effect on a normal user going to be, and should there be a 
news item?  As of now, there's a warning attached to the --dynamic-deps=n 
option in the emerge manpage, suggesting a fixpackages run if it's 
enabled.  If that's still recommended, switching to static-deps by 
default, and ultimately dropping dynamic-deps, really should trigger a 
news item suggesting that fixpackages run, for those with FEATURE buildpkg 
or buildsyspkg, anyway.

Additionally, from my own experience but AFAIK entirely undocumented, 
possibly due to my use of --with-bdeps=y, despite also having --newuse 
and consistently using --update --deep, switching to static-deps 
triggered a rebuild of a lot of packages depending on (IIRC) automake, 
because the way static-deps resolved it changed.  I didn't expect that 
because as I said, I normally update deep using newuse, so /thought/ I 
should be current, but apparently dynamic-deps wasn't as strict there as 
static-deps are.

I /think/ the --changed-deps option might avoid dealing with that 
manually now, so should it be enabled by default, and/or mentioned in the 
news item?  In any case, mentioning in the news item that a few extra 
rebuilds might be expected with this upgrade, and/or suggesting they be 
done previous to it (suggesting a --changed-deps run) could be wise.

Meanwhile, --changed-deps also invokes --selective by default, which will 
be a big change of behavior for many.  If --changed-deps is suggested in 
the news item (or becomes the default), the effect of --selective 
probably needs discussed as well.

Which probably is too much to easily fit a news item.  In such cases, the 
news item generally becomes a brief overview, with a link to (now) a wiki 
page, with further detail.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

On Thu, Sep 17, 2015 at 8:22 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> So council was called in, and it asked the portage folks to take some
> steps that, portage development being what it is, had the effect of
> slowing down and delaying things for long enough that, hopefully, people
> have had time to come to terms with the changes, and with a bit of
> familiarity, see static-deps aren't so bad, after all.

To be clear, the only thing the council did was ask the portage team
to clarify whether they intended to make it a default, and to provide
a plan/policy for virtuals/eclasses/etc.  There was a lot of the usual
panic on the lists and it wasn't actually clear whether anybody
intended to change anything or if we were making a lot of ado over
just an idea.

The purpose of the discussions on-list are mostly to try to go ahead
and figure out what we want to do with virtuals/eclasses/etc so that
the portage team can make the change when they're ready.  My
understanding is that they're now fairly eager to do so, but perhaps a
bit gun-shy about dealing with all the likely bikeshedding.   So, a
few council members broached the subject so that people can throw
their stones at us and maybe wear themselves out.  In this way we also
protect our generous salaries by making the job sound even less
enviable than it must already seem.  :)

A year ago this got an huge outcry.  Of late I'm barely hearing a
whimper of protest.  I think that people have been dealing with broken
dependency resolution long enough with subslots now that they just
want to see the pain go away.  From what I've heard it hasn't been too
painful to disable dynamic deps, and I never really had issues with it
with paludis when I was using it.  I did take a look at the results of
an emerge --changed-deps world and it came out to 388 packages to
rebuild, much of it being kde.

-- 
Rich

Re: [gentoo-dev] Re: Dynamic dependencies

[Zac Medico]

On 09/17/2015 05:22 PM, Duncan wrote:
> Ciaran McCreesh posted on Thu, 17 Sep 2015 20:31:36 +0100 as excerpted:
> 
>> On Thu, 17 Sep 2015 20:14:59 +0100 Markos Chandras <hwoarang@gentoo.org>
>> wrote:
>>> could someone explain what the dynamic dependencies are in the context
>>> of portage and ebuilds? because that does seem to be something
>>> portage-internal specific in the way it handles changes in {,R}DEPEND
>>> without revbumps. Where is this thing documented in the first place?
>>
>> Sometimes, Portage will sort of use the dependencies specified in an
>> ebuild rather than the dependencies specified in VDB for certain
>> operations under certain conditions and certain phases of the moon,
>> except when it doesn't. This is a quirk left over from the olden days,
>> when Portage could only handle the existence of one version of any given
>> package, and so couldn't cope with there being something called foo-1.2
>> in VDB and something else called foo-1.2 in the tree. This bug was
>> largely fixed when env saving meant that eclasses no longer had to
>> remain compatible with things in VDB, but traces of it still remain to
>> cause confusion.
> 
> [There's discussion of a potential news item below.  People familiar with 
> the dynamic-deps discussion in general may wish to skip to it.  See under 
> the "Possible News item?" heading.]
> 
> Additionally, AFAIK, portage entirely disables dynamic-deps and uses 
> static deps any time subslots are used.

Actually, in this case it uses a combination of static deps and dynamic
deps. It takes the "static" slot operator deps and merges them with the
dynamic deps. The relevant code is here:

https://gitweb.gentoo.org/proj/portage.git/tree/pym/_emerge/FakeVartree.py?h=v2.2.20.1#n137
-- 
Thanks,
Zac

[gentoo-dev] Re: Dynamic dependencies

[Duncan]

Rich Freeman posted on Thu, 17 Sep 2015 21:46:50 -0400 as excerpted:

> On Thu, Sep 17, 2015 at 8:22 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> So council was called in, and it asked the portage folks to take some
>> steps that, portage development being what it is, had the effect of
>> slowing down and delaying things for long enough that, hopefully,
>> people have had time to come to terms with the changes, and with a bit
>> of familiarity, see static-deps aren't so bad, after all.
> 
> To be clear, the only thing the council did was ask the portage team to
> clarify whether they intended to make it a default, and to provide a
> plan/policy for virtuals/eclasses/etc.

... And AFAIK, that "provide a plan" bit is what ultimately effected the 
delay... particularly as that's exactly what this thread is about, a year 
later.

Which seems to have been the wisdom of Solomon. =:^)  Certainly, some 
plan for eclasses in particular is needed, and somebody needs to come up 
with it.  And asking the party proposing the change to propose a least a 
draft plan for its execution is both traditional and reasonable.  The 
effect of that delaying things a year arguably wasn't entirely 
deliberate, but a delay of say six months at least, could probably have 
been predicted, if anyone thought about it.

> The purpose of the discussions on-list are mostly to try to go ahead and
> figure out what we want to do with virtuals/eclasses/etc so that the
> portage team can make the change when they're ready.  My understanding
> is that they're now fairly eager to do so, but perhaps a bit gun-shy
> about dealing with all the likely bikeshedding.   So, a few council
> members broached the subject so that people can throw their stones at us
> and maybe wear themselves out.  In this way we also protect our generous
> salaries by making the job sound even less enviable than it must already
> seem.  :)

I'm sure they're rather grateful, given the hue and cry[1] last time it 
was presented.  =:^/  As you seem to suggest, however, that's part of the 
job of the council, to be the "the buck stops here" guy when one is 
needed.

> A year ago this got an huge outcry.  Of late I'm barely hearing a
> whimper of protest.  I think that people have been dealing with broken
> dependency resolution long enough with subslots now that they just want
> to see the pain go away.

That was the "wisdom of Solomon" part.  While it did effect a delay, both 
you and I have noted the dramatic difference in tone this time around.

> From what I've heard it hasn't been too
> painful to disable dynamic deps, and I never really had issues with it
> with paludis when I was using it.  I did take a look at the results of
> an emerge --changed-deps world and it came out to 388 packages to
> rebuild, much of it being kde.

Either that --changed-deps, or some other change introduced in portage 
about the same time, seems to have dramatically reduced the number of
not-automatically-resolved blockers I had when I first started using
--dynamic-deps=n.  So my recent static-deps experience is thus indeed 
very reasonable and I agree suitable for default enabling.

But my early experience was far rougher, and I'm not /entirely/ sure what 
the difference is, tho I'm chalking it up to --changed-deps.  If indeed 
that is the difference, as I suggested, it should be considered for 
default along with static-deps, but as it does trigger more rebuilds and 
because of the changed --selective behavior it brings, I consider a news 
item critical, should it be suggested or become the default.

---
[1] Hue and cry:  LOL!  I just looked up the term to ensure I was using 
it appropriately, and it seems it's even more appropriate (and looking 
back at the events I'm describing with it, humorous) than I intended!  
Brits may be more familiar with the term's history than I was, but it 
seems that originally, the term referred to the pursuit of a criminal and 
ensuing general commotion, specifically the shouts to warn others to give 
chase.  That seems particularly descriptive of the commotion surrounding 
this idea last time it was brought up, with people scandalized by the 
very idea, calling for the idea and the people suggesting it to be 
rhetorically ridden out of town as criminals!  Such a contrast to this 
time!

https://en.wiktionary.org/wiki/hue_and_cry

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
nd if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 1:09 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> I'll go ahead and start a tangent on this thread right here.  As a
> first step can we separately consider the proposal to require a
> revbump anytime a package's RDEPENDS changes?  I'm referring here to
> directly-specified RDEPENDS, not those inherited from an eclass or
> virtual.

Ok, for the purpose of the upcoming council meeting, I'd like to make
a few separate proposals around dynamic dependencies.
There are three categories of policies:
1.  RDEPEND changes directly in ebuilds.
2.  RDEPEND changes directly in virtuals.
3.  RDEPEND changes in eclasses.

Honestly, I'm not really convinced virtuals need special treatment,
but I split them off in case it is useful in discussion.

RDEPEND changes directly in ebuilds
Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes directly in virtuals
Proposal 2: Anytime an RDEPEND in a virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.

Please speak up if you have any issues with any of these.

I'm leaning towards adopting 1, 2, and 4.  I would actually prefer 3
to 4 on principle, but we don't have a good way of retiring obsolete
eclasses and I don't want to see a huge multiplication in them.  If we
did adopt #3 we should probably start thinking about more consistent
version numbering for eclasses since I could see multiple active
series of eclass versions being updated in parallel.

I'll also note that the wording of Proposal 4 doesn't preclude doing
proposal 3 if the eclass maintainer thinks it is appropriate (maybe
the RDEPEND should only change in some circumstances or there are
other changes happening at the same time).  The wording of Proposal 4
refers to when an eclass is changed, and if you make the change in a
new revision you aren't changing the previous one, and so you don't
need to bump all the ebuilds.  Of course the ebuilds would still need
to be bumped if they were modified to use the new eclass, per proposal
1.

Proposal 3 is superior to proposal 4 from the standpoint of overlays
that use eclasses in the main repository, since nobody will be going
around and revbumping their ebuilds.  Of course, any eclass change
should be posted on -dev and so there would be notice.

Adopting 1, 2, and at least one of 3 or 4 would eliminate all the
dynamic dependency issues in the tree.  If anybody is aware of any
that I missed and I'll add them.

Also, in the event proposal 1 and 2 are both adopted, here is proposed
streamlined wording:
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the ebuild
must be revisioned.  This includes adding/removing inherited eclasses
which set RDEPENDs.

However, the council doesn't have to approve the literal wording of
everything in the devmanual, so that might be overkill.  The devmanual
can of course explain the rationale for avoiding dynamic deps/etc.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/10/15 02:34 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 1:09 PM, Rich Freeman <rich0@gentoo.org>
> wrote:
>> 
>> I'll go ahead and start a tangent on this thread right here.
>> As a first step can we separately consider the proposal to
>> require a revbump anytime a package's RDEPENDS changes?  I'm
>> referring here to directly-specified RDEPENDS, not those
>> inherited from an eclass or virtual.
> 
> Ok, for the purpose of the upcoming council meeting, I'd like to
> make a few separate proposals around dynamic dependencies. There
> are three categories of policies: 1.  RDEPEND changes directly in
> ebuilds. 2.  RDEPEND changes directly in virtuals. 3.  RDEPEND
> changes in eclasses.
> 
> Honestly, I'm not really convinced virtuals need special
> treatment, but I split them off in case it is useful in
> discussion.
> 
> RDEPEND changes directly in ebuilds Proposal 1: Anytime an
> RDEPEND in a non-virtual ebuild is changed, the ebuild must be
> revisioned.  This includes adding/removing inherited eclasses
> which set RDEPENDs.
> 

Seconded, with the exclusion of package renames, as those can be
handled in-place with 'pkgmove' VDB updates.

Slotmove VDB updates *should* be allow slotmove-related changes to
be excluded here too, but unfortunately with portage not doing
updates to rdeps properly, at this time all rdeps will need to be
revbumped when their RDEPEND changes.



> RDEPEND changes directly in virtuals Proposal 2: Anytime an
> RDEPEND in a virtual ebuild is changed, the ebuild must be
> revisioned.  This includes adding/removing inherited eclasses
> which set RDEPENDs.


Seconded; virtuals are empty so its not a big deal here


> 
> RDEPEND changes in eclasses Proposal 3: Anytime an RDEPEND in an
> eclass is changed, the eclass must be revisioned. Proposal 4:
> Anytime an RDEPEND in an eclass is changed, all ebuilds that
> inherit the eclass in the gentoo repository must be revisioned.

This one is trickier to deal with.  For starters, after thread
between yourself and mgorny and I, I think we figured out that there
wouldn't be an end-user breakage from people that have emerged a
package eclass-rdepend'ing on one depset, when that depset is
changed; it just ends up with everyone after the time of the change
needing the new depset.

There are specific cases where the revbump to rdeps will be
necessary (and the eclass itself too, *if* keeping the old eclass
around or differentiating which eclass version is inherited actually
matters):

- - slotmove operations on a dep in *DEPEND
- - the addition of blocker atoms due to the introduction of
conflicting packages
- - the addition of atoms to address implicit dependencies that were
missed before (and weren't in the ebuilds)
- - adjustments to atoms based on changes made to the dependent
package, with the changes now necessary to prevent breakage.  (IE:
useflags changed in-place on a dep and the packages inheriting the
eclass now need to ensure that the new useflag is set)

...there are likely other cases but I can't think of any right now.

At any rate, the point here being that a simple minimum-version-bump
in an eclass RDEPEND does indicate a divergence will occur between
end-user VDB and the repo, but that doesn't necessarily mean it's
something we need to avoid, or rather, we don't necessarily -need-
to enforce convergence between the repo and end-user VDB.


Once we get a bit more hashing out of the above I can try writing up
the complicated proposal(5?,6?) wording...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF0EAREIAAYFAlYNhJAACgkQAJxUfCtlWe2oXQD2ILHhFlsTJ8FYXbzSROA4hsnE
FGV17l9WmWr31NlrpQD+Iw5tbN/qzeDSZZXXv8/YbXu82IhgB5qK3FZjmxdEEkU=
=hYNh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2015 09:12 PM, Ciaran McCreesh wrote:
> On Thu, 1 Oct 2015 15:08:00 -0400 Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> Slotmove VDB updates *should* be allow slotmove-related changes
>> to be excluded here too, but unfortunately with portage not
>> doing updates to rdeps properly, at this time all rdeps will need
>> to be revbumped when their RDEPEND changes.
> 
> This is a severe misrepresentation of what the issue actually is.
> 

Thanks for pointing that out, would you please elaborate on what the
issue actually is for the purpose of this discussion?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWDYVWAAoJECULev7WN52FRIkIAIc+g+eUPVKNV7LujBCv0ogC
0C/1ESJlNv41N5+spdsP+CoRrpTeAj7cXkhGuYNniANUfmM9xtltGKSp5WLFtPd0
FqiM+UDmbAWlIFlpKA8IrPTNIOwM5QAthmU6Xo8+LJw57AZoG/r1XDUKIfToH7bU
vLpWz0dJudt9azFidOKHNM4ZCFlwqE5rVVEtL93iHyEuU4WM8EwzFsnVn+K2MnIz
7MXh3FvHzNjmiyxDzqzRpMzTElag0js15N9SHJp1CkJvRnL/kx6Ez+aas7l03rsb
DaTzgRgWsy9gFdf6x0308jw7bPSNEZW5F6liX8l8EFytNikIsVdmj4ZrhVyJ9Yw=
=2mDk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Thu, 1 Oct 2015 15:08:00 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> Slotmove VDB updates *should* be allow slotmove-related changes to
> be excluded here too, but unfortunately with portage not doing
> updates to rdeps properly, at this time all rdeps will need to be
> revbumped when their RDEPEND changes.

This is a severe misrepresentation of what the issue actually is.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Dynamic dependencies

[Michael Orlitzky]

On 10/01/2015 02:34 PM, Rich Freeman wrote:
> 
> RDEPEND changes directly in ebuilds
> Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
> ebuild must be revisioned.  This includes adding/removing inherited
> eclasses which set RDEPENDs.
> 

This gets conflated with dynamic dependencies, but really, it's already
necessary. Not doing so hurts users of other package managers, and even
users who use portage with dynamic dependencies turned off. The PMS is
the gospel here, so we should be following it. Thou shalt revbump. Doing
so does not cause unnecessary rebuilds, because the rebuilds are already
necessary, so they're not unnecessary.

Obviously I'm a +1, and I think we should push this through even if
there's ongoing discussion about the other proposals. I have a patch for
the devmanual[0] that would clarify this (existing) policy. Here's what
I suggest:

  Increment the revision number whenever you change an ebuild. New
  revisions are subject to the keyword policy for upgrades. A few
  exceptions to  this rule are outlined below. If you are unsure,
  increment the revision number. However, in the following cases, you
  may modify an ebuild in-place:

  WARNING: These exceptions do not apply to stable ebuilds. Only under
  /exceptional/ circumstances should you modify a stable ebuild.

    * Fixes for compilation failures. These do not affect users
      who have already managed to build the package, so there's no
      reason to force the package to be rebuilt.

    * Changes to comments.

    * Modification of build-time dependencies. Use this exception
      sparingly; for example, when the package takes a long time to
      compile.

Basically: revbump unless you happen to know better.



[0] https://560356.bugs.gentoo.org/attachment.cgi?id=411926

Re: [gentoo-dev] Dynamic dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Thu, 1 Oct 2015 21:11:22 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 10/01/2015 09:12 PM, Ciaran McCreesh wrote:
> > On Thu, 1 Oct 2015 15:08:00 -0400 Ian Stakenvicius <axs@gentoo.org>
> > wrote:
> >> Slotmove VDB updates *should* be allow slotmove-related changes
> >> to be excluded here too, but unfortunately with portage not
> >> doing updates to rdeps properly, at this time all rdeps will need
> >> to be revbumped when their RDEPEND changes.
> > 
> > This is a severe misrepresentation of what the issue actually is.
> > 
> 
> Thanks for pointing that out, would you please elaborate on what the
> issue actually is for the purpose of this discussion?

Some people expect Portage to do the impossible when handling slot
moves, on the basis that with a superficial understanding it looks like
it could partially work in certain easy cases. Thus "all rdeps will need
to be revbumped when their RDEPEND changes" is not an "at this time"
thing at all, but a genuine requirement.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2015 09:22 PM, Ciaran McCreesh wrote:
> On Thu, 1 Oct 2015 21:11:22 +0200 Kristian Fiskerstrand
> <k_f@gentoo.org> wrote:
>> On 10/01/2015 09:12 PM, Ciaran McCreesh wrote:
>>> On Thu, 1 Oct 2015 15:08:00 -0400 Ian Stakenvicius
>>> <axs@gentoo.org> wrote:
>>>> Slotmove VDB updates *should* be allow slotmove-related
>>>> changes to be excluded here too, but unfortunately with
>>>> portage not doing updates to rdeps properly, at this time all
>>>> rdeps will need to be revbumped when their RDEPEND changes.
>>> 
>>> This is a severe misrepresentation of what the issue actually
>>> is.
>>> 
>> 
>> Thanks for pointing that out, would you please elaborate on what
>> the issue actually is for the purpose of this discussion?
> 
> Some people expect Portage to do the impossible when handling slot 
> moves, on the basis that with a superficial understanding it looks
> like it could partially work in certain easy cases. Thus "all rdeps
> will need to be revbumped when their RDEPEND changes" is not an "at
> this time" thing at all, but a genuine requirement.
> 

Thank you. I generally prefer the always-revbump approach to avoid the
consideration of whether it is needed or not as a matter of KISS
policy, but that provides a valuable technical argument for it as well.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWDYgtAAoJECULev7WN52F8MsH/0SL0Iygoh7b4AzEIyNmczNW
dPei13uGkmxMx4IojDZYIr/j3iRevLuEaiXi1DJXBGvY61Y8tez08mqrzLJEDtvq
jeFxqk0Bm8p0XEQ2CMnk4wJuVkSrfvrwHpScCVW3T6yTiEmK6bbZUjhNTH+rEm8D
H5uBLYAgJblVjjUcBrYRT9y2EIdUT5miAN2I2YPzT3BpC4FPplrCvA4QvU2i32pj
giEQo7eM5krw2ygEh6Tln8T//mrdAx2OKFbgMgoSBYDQDHK/d2YT7anUBWeuAxQB
GfjvIZPmgYAShOOCq00FCqOW4amO2UpovkcxbKRUjgtJ83epa3RRXuhm7Hwcv5o=
=Rmqm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Thu, Oct 1, 2015 at 3:08 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
>>
>> RDEPEND changes in eclasses Proposal 3: Anytime an RDEPEND in an
>> eclass is changed, the eclass must be revisioned. Proposal 4:
>> Anytime an RDEPEND in an eclass is changed, all ebuilds that
>> inherit the eclass in the gentoo repository must be revisioned.
>
> This one is trickier to deal with.  For starters, after thread
> between yourself and mgorny and I, I think we figured out that there
> wouldn't be an end-user breakage from people that have emerged a
> package eclass-rdepend'ing on one depset, when that depset is
> changed; it just ends up with everyone after the time of the change
> needing the new depset.
>
> There are specific cases where the revbump to rdeps will be
> necessary (and the eclass itself too, *if* keeping the old eclass
> around or differentiating which eclass version is inherited actually
> matters):
>
> - - slotmove operations on a dep in *DEPEND
> - - the addition of blocker atoms due to the introduction of
> conflicting packages
> - - the addition of atoms to address implicit dependencies that were
> missed before (and weren't in the ebuilds)
> - - adjustments to atoms based on changes made to the dependent
> package, with the changes now necessary to prevent breakage.  (IE:
> useflags changed in-place on a dep and the packages inheriting the
> eclass now need to ensure that the new useflag is set)
>
> ...there are likely other cases but I can't think of any right now.
>
> At any rate, the point here being that a simple minimum-version-bump
> in an eclass RDEPEND does indicate a divergence will occur between
> end-user VDB and the repo, but that doesn't necessarily mean it's
> something we need to avoid, or rather, we don't necessarily -need-
> to enforce convergence between the repo and end-user VDB.
>
>
> Once we get a bit more hashing out of the above I can try writing up
> the complicated proposal(5?,6?) wording...

Agreed.  Thanks for bringing this up again.  If you're adding an RDEP
to an eclass in anticipation of it being necessary for new ebuilds but
all the ebuilds in the tree still work with the old RDEP, then the
bumping can be selective.

Rather than trying to identify specific cases, why not identify the
intent, and then we can build out the individual cases on the
devmanual, and revise it over time as necessary.

Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
eclass must be revisioned unless all ebuilds in the gentoo repository
will continue to work correctly with the old RDEPEND.
Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all
ebuilds that inherit the eclass in the gentoo repository must be
revisioned if they will not continue to work correctly with the old
RDEPEND.

There is no need to have the council approve revisions to the
devmanual every time somebody points out a new case where this
happens.  The goal here is to just let everybody air their opinions,
and set a general direction so that those implementing it don't get
caught in the crossfire.

It sounds like pkgmove should be added to all the proposals as an exception.

-- 
Rich

[gentoo-dev] Re: Dynamic dependencies

[Martin Vaeth]

Rich Freeman <rich0@gentoo.org> wrote:
>
> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
> eclass must be revisioned unless all ebuilds in the gentoo repository
> will continue to work correctly with the old RDEPEND.
> Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all
> ebuilds that inherit the eclass in the gentoo repository must be
> revisioned if they will not continue to work correctly with the old
> RDEPEND.

Adding an || alternative should be included here:
The installed package would continue to work without that alternative,
but without a revbump the user is not able to see that he might
possibly drop a package.

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

On Fri, Oct 2, 2015 at 2:22 AM, Martin Vaeth <martin@mvath.de> wrote:
> Rich Freeman <rich0@gentoo.org> wrote:
>>
>> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
>> eclass must be revisioned unless all ebuilds in the gentoo repository
>> will continue to work correctly with the old RDEPEND.
>> Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all
>> ebuilds that inherit the eclass in the gentoo repository must be
>> revisioned if they will not continue to work correctly with the old
>> RDEPEND.
>
> Adding an || alternative should be included here:
> The installed package would continue to work without that alternative,
> but without a revbump the user is not able to see that he might
> possibly drop a package.
>

Ugh, I agree completely but this isn't going to make the wording prettier.

Perhaps add "or if the new RDEPEND allows the ebuild to work with
additional dependencies."  Or maybe just straight out say "or if
additional || atoms are added."  The first wording might allow for
additional cases, which is probably good.

Otherwise a change is made today without a revbump and a year later
somebody removes some package from the tree and random users run into
problems with it.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/10/15 03:22 PM, Ciaran McCreesh wrote:
> On Thu, 1 Oct 2015 21:11:22 +0200 Kristian Fiskerstrand
> <k_f@gentoo.org> wrote:
>> On 10/01/2015 09:12 PM, Ciaran McCreesh wrote:
>>> On Thu, 1 Oct 2015 15:08:00 -0400 Ian Stakenvicius
>>> <axs@gentoo.org> wrote:
>>>> Slotmove VDB updates *should* be allow slotmove-related
>>>> changes to be excluded here too, but unfortunately with
>>>> portage not doing updates to rdeps properly, at this time
>>>> all rdeps will need to be revbumped when their RDEPEND
>>>> changes.
>>> 
>>> This is a severe misrepresentation of what the issue actually
>>> is.
>>> 
>> 
>> Thanks for pointing that out, would you please elaborate on
>> what the issue actually is for the purpose of this discussion?
> 
> Some people expect Portage to do the impossible when handling
> slot moves, on the basis that with a superficial understanding it
> looks like it could partially work in certain easy cases. Thus
> "all rdeps will need to be revbumped when their RDEPEND changes"
> is not an "at this time" thing at all, but a genuine
> requirement.
> 

I think "for the purpose of this discussion" is the relevant point
of K_F's question -- that is, is there a severe misrepresentation on
the need to revbump all ebuilds of rdeps when a package changes its
SLOT= ?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlYOi7UACgkQAJxUfCtlWe2LlgD+I6vLjXGDPfq1/ojscXVrMp0A
jUHv4qE6Yl91mTqp1e8A/jWTkKJdqMB8y70jE7LdHZAHIRS4JvpOkW1UEQmHHxwe
=ZOTx
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

On Fri, Oct 2, 2015 at 5:46 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Oct 2, 2015 at 2:22 AM, Martin Vaeth <martin@mvath.de> wrote:
>> Rich Freeman <rich0@gentoo.org> wrote:
>>>
>>> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
>>> eclass must be revisioned unless all ebuilds in the gentoo repository
>>> will continue to work correctly with the old RDEPEND.
>>> Proposal 4a might be: Anytime an RDEPEND in an eclass is changed, all
>>> ebuilds that inherit the eclass in the gentoo repository must be
>>> revisioned if they will not continue to work correctly with the old
>>> RDEPEND.
>>
>> Adding an || alternative should be included here:
>> The installed package would continue to work without that alternative,
>> but without a revbump the user is not able to see that he might
>> possibly drop a package.
>>
>
> Perhaps add "or if the new RDEPEND allows the ebuild to work with
> additional dependencies."  Or maybe just straight out say "or if
> additional || atoms are added."  The first wording might allow for
> additional cases, which is probably good.
>

So, here is a consolidated list of the latest proposals:

RDEPEND changes directly in ebuilds (non-virtual and virtual)
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.


RDEPEND changes in eclasses
Proposal 3b: Anytime an RDEPEND in an eclass is changed, the
eclass must be revisioned unless:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND


Proposal 4b: Anytime an RDEPEND in an eclass is changed, all
ebuilds that inherit the eclass in the gentoo repository must be
revisioned unless:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND.


From the tone of discussion the wording of the eclass proposals still
might be a bit conservative, and there may be other cases where we
could avoid bumps.  However, I think this does cover the examples that
actually came up.


Here are ones that i consider outdated:
RDEPEND changes directly in ebuilds
Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes directly in virtuals
Proposal 2: Anytime an RDEPEND in a virtual ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.

RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.
Proposal 3a: Anytime an RDEPEND in an eclass is changed, the
eclass must be revisioned unless all ebuilds in the gentoo repository
will continue to work correctly with the old RDEPEND.
Proposal 4a: Anytime an RDEPEND in an eclass is changed, all
ebuilds that inherit the eclass in the gentoo repository must be
revisioned if they will not continue to work correctly with the old
RDEPEND.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand <k_f@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

Re: [gentoo-dev] Dynamic dependencies

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/11/2015 01:21 PM, Rich Freeman wrote:
> On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand 
> <k_f@gentoo.org> wrote:
>> 
>> Another thing that strikes me is separation of stable vs ~arch 
>> behavior.
>> 


..

> 
> 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 think we are mostly in agreement, actually, the point wasn't about
the rebuild following a bump (which is necessary for vdb update and
indeed gets rid of issues down the road), it was more about whether it
is prudent to change eclasses used by stable packages without bumping
revision, and being careful in this consideration when selecting to
set deps in eclasses rather than directly in ebuild in the first place.

> 
> 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.

Yeah, I don't think this discussion impacts the proposals you've
outlined for dyndeps, thanks for summing things up.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWGkguAAoJECULev7WN52Fz7AIAK9CqQTXmduz17pydV4yzHwX
VIkEQ/5p+BoJixEceSLJo1KN2IBcDNHeZeyUgjxbY3yO/LuB+VzNzQk87gvaAKGw
EY81KJy7Y44vzejeMR1k1c7nnAtgaoyYgd2xAce57BPwvHVRtNJPTZeyvOunQiMo
bq5fB2IMrPrd59NdaM0ncF2Z5Cpx/0RMMyo2tQK2wTdF7I4upzjWiR9EwM39yyhC
OIHLXO6pj+1fFxrtUAPV5lnBs15FxRKwLRNfDOcvhOKlHnjgr9QinJcG4gvczq7+
v/Faw/NNO1b5qzYcprQsvWEk4lBvy29RF555cBxvEWU3z9LhyDbXdQldY6QNy4c=
=9Vcc
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

On Sun, Oct 11, 2015 at 7:09 AM, Rich Freeman <rich0@gentoo.org> wrote:
> So, here is a consolidated list of the latest proposals:
>

It has been suggested that there might be rare cases where the
exceptions in the eclass proposals might apply to ebuilds, so doing
some refactoring I think the latest proposals are:

RDEPEND changes directly in ebuilds (non-virtual and virtual)
Proposal 5: Anytime an RDEPEND in an ebuild is changed, the
ebuild must be revisioned.  This includes adding/removing inherited
eclasses which set RDEPENDs.


RDEPEND changes in eclasses
Proposal 3: Anytime an RDEPEND in an eclass is changed, the eclass
must be revisioned.
Proposal 4: Anytime an RDEPEND in an eclass is changed, all ebuilds
that inherit the eclass in the gentoo repository must be revisioned.

General exception to the above:
Proposal 6: Maintainers may avoid revbumps at their discretion if:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND

(Ironically splitting that out just reverts us back to the original
proposals, but it is also simpler.)

-- 
Rich

Re: [gentoo-dev] Re: Dynamic dependencies

[Rich Freeman]

Ok, in the Council meeting today the following was made policy:
"Maintainers must not assume that dynamic dependencies will be applied
by the package manager. When changing runtime dependencies the
maintainer should revision the ebuild if the changes are likely to
cause problems for end users."

The wording intentionally left some room for maintainer discretion,
but this should be used with care.  Eclass changes were really the
main area of concern, and it was suggested that it would be a good
practice to talk about whether bumping makes sense when discussing the
eclass change on -dev as already required by policy.

The proposals I sent out earlier will be adopted as guidelines.  They
can go in the devmanual once they're worked out here, and can be
maintained as with anything else in the devmanual.  Adding additional
edge cases/etc them doesn't require explicit council approval
(obviously large controversies can always be appealed).

Guidelines:

RDEPEND changes directly in ebuilds
Anytime an RDEPEND in an ebuild is changed, the ebuild should be
revisioned.  This includes adding/removing inherited eclasses which
set RDEPENDs.

RDEPEND changes in eclasses
Anytime an RDEPEND in an eclass is changed, all ebuilds that inherit
the eclass in the gentoo repository should be revisioned.
It is generally going to be easier to do that all at once, but it may
make sense in some cases to revision the eclass itself to allow
gradual adoption of the change.  Ebuilds would be revisioned as they
adopt the new eclass.

General exception to the above:
There are cases where a change in runtime dependencies will not cause problems.

Maintainers may safely avoid revbumps if:
1. all ebuilds in the gentoo repository will continue to work
correctly with the old RDEPEND,
2. and the new RDEPEND is a subset of the old RDEPEND

A common example of a situation where a bump is not needed is when
increasing the minimum version of a dependency in an eclass, when the
old version was working for all ebuilds that used the eclass at the
change (i.e. the change is being made for the sake of ebuilds that are
about to be introduced to the tree).

Please reply if you see any need to improve these.  I would encourage
developers to take these guidelines seriously.  The purpose of
allowing discretion is so that we're not locked into rigid rules that
don't capture every nuance.  If you change an RDEPEND and don't bump
it can cause subtle problems that can show up weeks or months later,
when devs make changes that repoman considers valid but which are
inconsistent with what is recorded on user's vdbs.

-- 
Rich