Re: [gentoo-portage-dev] custom profiles?

[Zac Medico]

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