On 5/16/21 2:24 PM, Andreas Fink wrote:
On Sun, 16 May 2021 13:14:26 +0200
n952162 <n952...@web.de> wrote:
On 5/16/21 12:53 PM, Andreas Fink wrote:
On Sun, 16 May 2021 12:49:26 +0200
n952162 <n952...@web.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.
