1 |
On Sat, 8 Jul 2017 20:27:38 -0400 |
2 |
"Walter Dnes" <waltdnes@××××××××.org> wrote: |
3 |
> |
4 |
> > Though I will have to see what happens if a package is listed in |
5 |
> > more than one set. I think there is a hierarchy there. |
6 |
> |
7 |
> I tried "emerge -pv --unmerge @palemoon_build", and it was ready to |
8 |
> delete all the stuff, including gcc, etc. |
9 |
|
10 |
Did you get any warnings? Your about to remove a system package, etc. |
11 |
|
12 |
> > Not to mention if it was removed. I think the world or system set |
13 |
> > would pull it back in. |
14 |
> |
15 |
> Kind of hard to "pull it back in" if gcc or glib or ncurses isn't |
16 |
> present. This is rather dangerous. The problem is that, unlike an |
17 |
> ebuild, "emerge --unmerge @set" removes all packages in the set, |
18 |
> regardless of whether they're required by another package or not. |
19 |
|
20 |
It is the same as doing emerge -C gcc. At the same time if you built and |
21 |
generated a binary package. On re-emerge you could pull in the gcc |
22 |
binary you made when it was installed the first time. I love binary |
23 |
packages, I make and use them all the time. Invaluable for re-emerging. |
24 |
|
25 |
If you are making sets, adding system packages, and removing those. I |
26 |
would assume you are doing that as some sort of testing. Which would |
27 |
want to re-emerge/install those packages. Depending on what your doing |
28 |
very likely would want to make and use binaries in that process. Surely |
29 |
if removing system packages :) |
30 |
|
31 |
> I deleted /etc/portage/sets/palemoon_build, and the entry |
32 |
> "@palemoon_build" from /var/lib/portage/world_sets. It turns out that |
33 |
> all these packages are required anyways. |
34 |
|
35 |
Meaning little was removed after you did emerge --depclean world ? |
36 |
|
37 |
-- |
38 |
William L. Thomson Jr. |