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