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

[Brian Dolbec <dolsen@gentoo.org>]

On Wed, 11 Mar 2015 20:16:06 +0000
Joakim Tjernlund <joakim.tjernlund@transmode.se> 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>