1 |
Fundamentally, autounmask seems like something I don't want to do, at all. What happens if I just remove zz-autounmask? What do I have to emerge to find out? |
2 |
|
3 |
I currently have: |
4 |
|
5 |
$ cat /etc/portage/package.use/zz-autounmask |
6 |
>=dev-lang/python-2.7.14-r1:2.7 sqlite |
7 |
>=sys-libs/zlib-1.2.11-r1 minizip |
8 |
|
9 |
And, I thought unmasking was related to keywords - allowing or not allowing experimental versions ... why is that in /etc/portage/package.use? |
10 |
|
11 |
|
12 |
|
13 |
> Gesendet: Dienstag, 04. Juni 2019 um 00:09 Uhr |
14 |
> Von: n952162@×××.de |
15 |
> An: gentoo-user@l.g.o |
16 |
> Betreff: Aw: Re: [gentoo-user] Updating portage, continued |
17 |
> |
18 |
> I'm sorry, I'm not getting this yet. What if I just don't update these configuration files? |
19 |
> |
20 |
> dispatch-conf tells me, for /etc/portage/package.accept_keywords: |
21 |
> |
22 |
> --- /etc/portage/package.use/zz-autounmask 2018-03-12 21:56:49.172491972 +0100 |
23 |
> +++ /etc/portage/package.use/._cfg0015_zz-autounmask 2018-07-28 11:08:23.725995803 +0200 |
24 |
> @@ -1,2 +1,5 @@ |
25 |
> >=dev-lang/python-2.7.14-r1:2.7 sqlite |
26 |
> >=sys-libs/zlib-1.2.11-r1 minizip |
27 |
> +# required by www-misc/monitorix-3.9.0::gentoo |
28 |
> +# required by monitorix (argument) |
29 |
> +>=net-analyzer/rrdtool-1.6.0-r1 perl graph |
30 |
> |
31 |
> I can zap it or merge it or skip it. It looks like the emerge was successful, so, why should I do anything? |
32 |
> |
33 |
> $ rrdtool |
34 |
> RRDtool 1.6.01.6.0 Copyright by Tobias Oetiker <tobi@×××××××.ch> |
35 |
> |
36 |
> |
37 |
> I would have thought that emerge would pend until I'd agreed to the override. But, it apparently went ahead and installed. |
38 |
> So what's required still? What will be different once I make the merge to zz-autounmask? |
39 |
> |
40 |
> |
41 |
> |
42 |
> |
43 |
> > Gesendet: Donnerstag, 30. Mai 2019 um 14:33 Uhr |
44 |
> > Von: "Rich Freeman" <rich0@g.o> |
45 |
> > An: gentoo-user@l.g.o |
46 |
> > Betreff: Re: [gentoo-user] Updating portage, continued |
47 |
> > |
48 |
> > On Wed, May 29, 2019 at 6:37 PM <n952162@×××.de> wrote: |
49 |
> > > |
50 |
> > > The next section of the response to my attempt to update portage is a long list of packages, each terminated with a "(masked by: something or other)". |
51 |
> > > |
52 |
> > > What does that tell me. If it's masked, it shouldn't be available, right? But, I've got it: |
53 |
> > > |
54 |
> > > - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask) |
55 |
> > > |
56 |
> > > ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild |
57 |
> > > virtual/perl-parent/perl-parent-0.234.0-r1.ebuild |
58 |
> > > |
59 |
> > > Can I get rid of it? Is perl-parent always masked? |
60 |
> > > |
61 |
> > |
62 |
> > I think one of the issues here is that you might be running a bit with |
63 |
> > scissors. |
64 |
> > |
65 |
> > It seems like you might be using package.keywords, and now you're |
66 |
> > dealing with package masks. |
67 |
> > |
68 |
> > Portage will let you override just about anything, but those default |
69 |
> > behaviors all exist for a reason and you can easily end up painting |
70 |
> > yourself into a corner. Overriding keywords is something that isn't |
71 |
> > too unsafe to do once you know what you're doing, but if you're doing |
72 |
> > it a lot it can get out of hand (adding keywords for one package can |
73 |
> > require 3 more, and if you keep that up it can really get out of |
74 |
> > hand). If you're overriding keywords frequently perhaps you should be |
75 |
> > running the testing branch in the first place, etc. |
76 |
> > |
77 |
> > Overriding masks is something that should only be done if you REALLY |
78 |
> > know what you're doing. If something is masked it might contain |
79 |
> > security vulnerabilities, or it might be going away. The consequences |
80 |
> > of the former are obvious. If it is going away then you're going to |
81 |
> > be fighting to keep things working because the next step will be |
82 |
> > removal and other packages will start being modified to not work with |
83 |
> > the old approach. |
84 |
> > |
85 |
> > Basically, any setting you put in /etc/portage is something you're |
86 |
> > going to have to work to maintain, so you should be doing whatever you |
87 |
> > can to minimize this. By all means speak up on the list about "I'm |
88 |
> > trying to accomplish this, and is there a better way to go about it?" |
89 |
> > If you're creating a ton of entries in /etc/portage you might be |
90 |
> > fighting the package manager more than necessary. There is nothing |
91 |
> > wrong with customizing things (that is basically what Gentoo is for), |
92 |
> > but you definitely need to learn how to manage that so that you don't |
93 |
> > make life hard on yourself. |
94 |
> > |
95 |
> > -- |
96 |
> > Rich |
97 |
> > |
98 |
> > |
99 |
> |
100 |
> |