Re: [gentoo-user] What does emerge status R mean?

[n952162]

On 5/16/21 2:24 PM, Andreas Fink wrote:
> On Sun, 16 May 2021 13:14:26 +0200
> n952162 <n952162@×××.de> wrote:
>
>> On 5/16/21 12:53 PM, Andreas Fink wrote:
>>> On Sun, 16 May 2021 12:49:26 +0200
>>> n952162 <n952162@×××.de> wrote:
>>>
>>>> On 5/16/21 11:28 AM, Neil Bothwick wrote:
>>>>> On Sun, 16 May 2021 11:26:37 +0200, n952162 wrote:
>>>>>
>>>>>>>> There are no use flags defined for any of the packages I did a random
>>>>>>>> check for, either on the server or the client.  I am worried that it
>>>>>>>> is as you say: that the ebuild has a change of USE flags, which, of
>>>>>>>> course, has nothing to do with me, the user.
>>>>>>> As already stated, any USE flag changes would appear in the emerge
>>>>>>> output, this is most likely caused by --changed-deps. Try with
>>>>>>> --changed-use but without --changed-deps to see.
>>>>>>>
>>>>>>>
>>>>>> I have introduced that into my build script.  But, if it's as you say,
>>>>>> the one is a subset of the other, it should have no effect on the
>>>>>> output, right?
>>>>>>
>>>>> --changed-use is a subset of --newuse. --changed-deps is separate.
>>>>>
>>>>>
>>>> Ah, I oversaw that.
>>>>
>>>> Ah. why would I want to have --changed-deps anyway?  That suddenly seems
>>>> silly.
>>>>
>>>> It's unfortunate, if there's no explanatory display if a package got
>>>> disqualified for that reason.
>>>>
>>>>
>> Trying to comprehend here...
>>
>>> If you want to have a binhost, then --changed-deps will become
>>> "necessary" at some point. Let me draw you a picture, where a binhost
>>> would fail to provide the correct package:
>>>    - Binhost builds on day 1 package XYZ(i.e. server updates from internet)
>>>    - computer that would merge with packages from binhost is NOT updated(client does NO emerge on that day)
>>>    - the dependencies are changed on day 2(i.e. XYZ is emerged onto server, with changed dependencies in the ebuild)
>>>    - Binhost does NOT rebuild, because you do not have --changed-deps
>>>      enabled on day 2*(what is "Binhost" here? The --changed-deps is specified on the client)*
>>>    - Computer that merges from the binhost is updated on day 2 but will
>>>      NOT use the binary package from binhost, because the dependencies do
>>>      not match
>>> There are flags to ignore dependency mismatches, but the default would
>>> just not use the binary package.
>>>
>>> Cheers
>>> Andreas
>>>
>> What does changed-deps mean, actually?
>>
>>          --changed-deps [ y | n ]
>>                 Tells  emerge  to  replace  installed  packages for which
>> the corresponding
>>                 ebuild dependencies have changed since the packages were
>> built. ...
>>
>> I presume it means that a package needed XYZ before, but now needs
>> XYZZ.  If I don't specify --changed-deps, that I might get a run-time
>> resolution problem.
> Changed dependencies means any change in the *.ebuild file with respect
> to the variables DEPEND/BDEPEND/RDEPEND/PDEPEND, e.g. version of a
> dependent package has changed, new package was added as dependency, a
> package was removed as dependency. All are dependency changes. If the
> changed *.ebuild file is commited to the portage tree WITHOUT a
> version-bump/revision-bump, then emerge would NOT rebuild the package,
> unless --changed-deps is given as an argument.
>
>> Or, does it mean that the package specified XYZ.1 in an excess of
>> precision and the new version specifies XYZ.3?
>>
>> I just ran into this:
>>
>> --binpkg-changed-deps [ y | n ]
>>                 Tells  emerge  to  ignore binary packages for which the
>> corresponding ebuild
>>                 dependencies have changed since the packages were built.
>> In order  to  help
>>                 avoid  issues with resolving inconsistent dependencies,
>> this option is auto-
>>                 matically enabled unless the --usepkgonly option is
>> enabled.  Behavior  with
>>                 respect to changed build-time dependencies is controlled
>> by the --with-bdeps
>>                 option.
>>
>> But I haven't figured out what it means yet.  In particular, what all
>> the stated implications mean.
>>
> This would be the option to ignore dependency mismatches of what the
> binary package claims its dependencies are (which you could see  in
> $PKGDIR/Packages), and what the resolved dependencies are according to
> the *.ebuild file as portage is seeing it right now.
>
> Cheers
> Andreas
>

Thank you.