On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
> On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
> > On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
> > > On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
> > > > On Sun, 2015-03-08 at 15:47 +0000, Joakim Tjernlund wrote:
> > > > >
> > > > > package.use/package.use.force is a bit different though:
> > > > > cat /etc/portage/package.use/qemu
> > > > > app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl
> > > > > qemu_user_targets_x86_64 xattr virtfs
> > > > > static-
> > > > > user
> > > > >
> > > > > #Needed by static-user
> > > > > sys-libs/zlib static-libs
> > > > > dev-libs/glib static-libs
> > > > > sys-apps/attr static-libs
> > > > >
> > > > > Moving this to package.use/package.use.force does not respect -alsa,
> > > > > -pulseaudio, -opengl all
> > > > > flags which has a - on them, emerge wants to turn them on again.
> > > > >
> > > > > Am I missing something?
> > > > > Using portage 2.2.18
> > > >
> > > > Appears one have to use package.use.mask for that.
> > > > cat package.use.mask
> > > > app-emulation/qemu alsa pulseaudio bluetooth opengl
> > > > It would be handy if one could use the same syntax as in
> > > > /etc/portage/package.use/qemu(-alsa -opengl
> > > > etc.)
> > > >
> > > > Jocke
> > > >
> > >
> > > Yes, the inverted use.mask logic can be confusing if you are not familiar
> > > with it. The negative flags
> > > have a
> > > special meaning within the context of of portage's "incremental stacking"
> > > behavior, so they can still
> > > be
> > > useful, though not in the same way that you you attempted to use them.
> >
> >
> > So now I got to binary pkgs and profiles, the profile is typically part of
> > ebuild src tree/overlay
> > and a system using only binary pkgs does not need ebuild sources. How does
> > one manage profiles
> > is this case?
> > Just sync an empty /usr/portage tree(sans profile) or is the a better way?
>
> Recent portage has emerge --sync --sync-submodule=profile, which might be
> useful. I would like to work
> toward handling this case better, so your feedback is welcome.
That would the same as pointing portage to your own empty tree(sans profile). I
was hoping for
something connected to your BINHOST so one can get all in one go and stored in
the same directory
tree.
>
> >
> > Jocke
> >
> > PS.
> > emerge --depclean refuses to clean a system which is lagging behind,
> > would it be possible for
> > --depclean to go ahead anyway somehow? --dynamic-deps=n comes to mind.
>
> You should probably put --dynamic-deps=n in EMERGE_DEFAULT_OPTS, since this
> option
> typically causes these kinds of problems with --depclean. You don't need
> --dynamic-deps if you use --
> changed-deps when updating.
If I do --dynamic-deps=n then man emerge suggest to also do fixpackages(I guess
after every SYNC)
which feels a bit heavy, is this still needed?
Why is --dynamic-deps=y default? This feels like lying about your true deps, I
am probably missing
something here, an example would be great:)
Will --depclean with --dynamic-deps=n always succeed? I realize that it could
be dangerous but
sometimes would like to have the option.
BTW, this text is hard to parse:
--binpkg-changed-deps [ y | n ]
Tells emerge to ignore binary packages for which the
corresponding ebuild depen‐
dencies have changed since the packages were built. In order to
help avoid issues
with resolving inconsistent dependencies, this option is
automatically enabled
unless the --usepkgonly option is enabled. Behavior with
respect to changed
build-time dependencies is controlled by the --with-bdeps option.
--binpkg-changed-deps=y -> Ignore bin pkgs with changed deps?
