On 03/11/2015 01:16 PM, Joakim Tjernlund 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.
Yeah, I'll have to think about that. Maybe we could include a profile URI in the header of the Packages file. >> >>> >>> 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? Not really, because package moves are applied automatically after each emerge --sync. This happens unconditionally since FEATURES=fixpackages was removed [1], unless you use the emerge --package-moves=n option, in which case we assume that you will manage the consequences yourself. > 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:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). > Will --depclean with --dynamic-deps=n always succeed? I realize that it could > be dangerous but > sometimes would like to have the option. For the most part, yes. However, you may need to use --with-bdeps=y for updates, in order to avoid dependency breakage for build-time-only dependencies. > 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? Yeah, well it's not always easy to translate what the code does into human language. [1] https://github.com/gentoo/portage/commit/7ab4d5722a828167dd1bf946b26cfa80808f59fc -- Thanks, Zac
