On Wed, 11 Mar 2015 20:16:06 +0000 Joakim Tjernlund <[email protected]> wrote:
> 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:) Because the last time we even discussed the possibility of changing this and steps that might be to fix problems,... There were a few individuals that raised such a stink about it, they even brought it to council to have us STOPPED. So, as a result much of the portage team don't feel like working on portage. Heaven forbid we actually make a change! > > 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? -- Brian Dolbec <dolsen>
