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

[Joakim Tjernlund]

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?