1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Michael Marineau wrote: |
5 |
| I have a couple questions about why portage handles masked packages. |
6 |
oops, typo. *how* portage handles masked packages. |
7 |
| |
8 |
| First of all, when a specific masked package is emerged (usually a |
9 |
| ~mask) and |
10 |
| it is depended on by another package emerge -UD world will fail because |
11 |
| of the |
12 |
| masked dependency. This can be avoided by specifically unmasking the |
13 |
| package, |
14 |
| but that can be a bit tedious if this situation is a common occurrence. |
15 |
| Failing seems the right thing to do if the masked package is not already |
16 |
| installed, but if the package is already installed it would make sense |
17 |
| to me |
18 |
| that portage realizes that the dependency is already met and not die. |
19 |
| |
20 |
| Another thought that I made a comment on in the GLEP 19 thread is that if a |
21 |
| package is removed from the portage tree, later when upgrading another |
22 |
| the user |
23 |
| will be forced to upgrade(or downgrade if upgrades are masked) that |
24 |
| package to, |
25 |
| even if they wanted to keep the existing version. To get around this |
26 |
| the user |
27 |
| must save the old ebuild to their portage overly. I think it would make |
28 |
| more |
29 |
| sense to let the existing set of installed packages behave as another |
30 |
| portage |
31 |
| overly so that it is easy to hold on existing packages. This would also |
32 |
| avoid |
33 |
| any accidental downgrades if a package was ~arch masked, but then |
34 |
| removed from |
35 |
| portage in favor of a newer version. |
36 |
| |
37 |
| -- |
38 |
| Michael Marineau |
39 |
| marineam@×××××××××.edu |
40 |
| Oregon State University |
41 |
|
42 |
-----BEGIN PGP SIGNATURE----- |
43 |
Version: GnuPG v1.2.4 (GNU/Linux) |
44 |
|
45 |
iD8DBQFBAaIpiP+LossGzjARAhebAKDEQYeGEfsEsgDBr66xLqHpeaeOiACgmGTx |
46 |
pMKIi6cooDr7Rlr4euV10UE= |
47 |
=hFrN |
48 |
-----END PGP SIGNATURE----- |
49 |
|
50 |
-- |
51 |
gentoo-dev@g.o mailing list |