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.

> 
>  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.
-- 
Thanks,
Zac

Reply via email to