1 |
On Wed, 11 Mar 2015 20:16:06 +0000 |
2 |
Joakim Tjernlund <joakim.tjernlund@×××××××××.se> wrote: |
3 |
|
4 |
> On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: |
5 |
> > On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: |
6 |
> > > On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: |
7 |
> > > > On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: |
8 |
> > > > > On Sun, 2015-03-08 at 15:47 +0000, Joakim Tjernlund wrote: |
9 |
> > > > > > |
10 |
> > > > > > package.use/package.use.force is a bit different though: |
11 |
> > > > > > cat /etc/portage/package.use/qemu |
12 |
> > > > > > app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl |
13 |
> > > > > > qemu_user_targets_x86_64 xattr virtfs static- |
14 |
> > > > > > user |
15 |
> > > > > > |
16 |
> > > > > > #Needed by static-user |
17 |
> > > > > > sys-libs/zlib static-libs |
18 |
> > > > > > dev-libs/glib static-libs |
19 |
> > > > > > sys-apps/attr static-libs |
20 |
> > > > > > |
21 |
> > > > > > Moving this to package.use/package.use.force does not |
22 |
> > > > > > respect -alsa, -pulseaudio, -opengl all flags which has a - |
23 |
> > > > > > on them, emerge wants to turn them on again. |
24 |
> > > > > > |
25 |
> > > > > > Am I missing something? |
26 |
> > > > > > Using portage 2.2.18 |
27 |
> > > > > |
28 |
> > > > > Appears one have to use package.use.mask for that. |
29 |
> > > > > cat package.use.mask |
30 |
> > > > > app-emulation/qemu alsa pulseaudio bluetooth opengl |
31 |
> > > > > It would be handy if one could use the same syntax as |
32 |
> > > > > in /etc/portage/package.use/qemu(-alsa -opengl etc.) |
33 |
> > > > > |
34 |
> > > > > Jocke |
35 |
> > > > > |
36 |
> > > > |
37 |
> > > > Yes, the inverted use.mask logic can be confusing if you are |
38 |
> > > > not familiar with it. The negative flags have a |
39 |
> > > > special meaning within the context of of portage's "incremental |
40 |
> > > > stacking" behavior, so they can still be |
41 |
> > > > useful, though not in the same way that you you attempted to |
42 |
> > > > use them. |
43 |
> > > |
44 |
> > > |
45 |
> > > So now I got to binary pkgs and profiles, the profile is |
46 |
> > > typically part of ebuild src tree/overlay and a system using only |
47 |
> > > binary pkgs does not need ebuild sources. How does one manage |
48 |
> > > profiles is this case? Just sync an empty /usr/portage tree(sans |
49 |
> > > profile) or is the a better way? |
50 |
> > |
51 |
> > Recent portage has emerge --sync --sync-submodule=profile, which |
52 |
> > might be useful. I would like to work toward handling this case |
53 |
> > better, so your feedback is welcome. |
54 |
> |
55 |
> That would the same as pointing portage to your own empty tree(sans |
56 |
> profile). I was hoping for something connected to your BINHOST so one |
57 |
> can get all in one go and stored in the same directory tree. |
58 |
> |
59 |
> > |
60 |
> > > |
61 |
> > > Jocke |
62 |
> > > |
63 |
> > > PS. |
64 |
> > > emerge --depclean refuses to clean a system which is lagging |
65 |
> > > behind, would it be possible for --depclean to go ahead anyway |
66 |
> > > somehow? --dynamic-deps=n comes to mind. |
67 |
> > |
68 |
> > You should probably put --dynamic-deps=n in EMERGE_DEFAULT_OPTS, |
69 |
> > since this option typically causes these kinds of problems with |
70 |
> > --depclean. You don't need --dynamic-deps if you use -- |
71 |
> > changed-deps when updating. |
72 |
> |
73 |
> If I do --dynamic-deps=n then man emerge suggest to also do |
74 |
> fixpackages(I guess after every SYNC) which feels a bit heavy, is |
75 |
> this still needed? |
76 |
> |
77 |
> Why is --dynamic-deps=y default? This feels like lying about your |
78 |
> true deps, I am probably missing something here, an example would be |
79 |
> great:) |
80 |
|
81 |
|
82 |
Because the last time we even discussed the possibility of changing |
83 |
this and steps that might be to fix problems,... There were a few |
84 |
individuals that raised such a stink about it, they even brought it to |
85 |
council to have us STOPPED. |
86 |
|
87 |
So, as a result much of the portage team don't feel like working on |
88 |
portage. Heaven forbid we actually make a change! |
89 |
|
90 |
|
91 |
> |
92 |
> Will --depclean with --dynamic-deps=n always succeed? I realize that |
93 |
> it could be dangerous but sometimes would like to have the option. |
94 |
> |
95 |
> |
96 |
> BTW, this text is hard to parse: |
97 |
> --binpkg-changed-deps [ y | n ] |
98 |
> Tells emerge to ignore binary packages for which the |
99 |
> corresponding ebuild depen‐ dencies have changed since the packages |
100 |
> were built. In order to help avoid issues with resolving |
101 |
> inconsistent dependencies, this option is automatically enabled |
102 |
> unless the --usepkgonly option is enabled. Behavior with |
103 |
> respect to changed build-time dependencies is controlled by the |
104 |
> --with-bdeps option. |
105 |
> |
106 |
> --binpkg-changed-deps=y -> Ignore bin pkgs with changed deps? |
107 |
|
108 |
|
109 |
-- |
110 |
Brian Dolbec <dolsen> |