1 |
On Thu, 21 Dec 2006 19:36:59 +0200, Uwe Thiem wrote: |
2 |
|
3 |
> > package.provided is intended for use when you install something |
4 |
> > without portage - it's your way of telling portage the package is |
5 |
> > installed even though it's not in the database. |
6 |
> |
7 |
> What is that good for? Say I write my own app (like the one my |
8 |
> signature refers to) and install it system-wide without creating an |
9 |
> ebuild, what does it change if I put it into package.provided? I mean |
10 |
> portage doesn't know anything about it either way. |
11 |
|
12 |
It changes nothing in that case, but that's not what it is for. |
13 |
package.provided is for use when a package is in portage but you have |
14 |
chosen to install it independently. Say package A depends on package B, |
15 |
but you don;t want package B installed through portage (maybe you want |
16 |
the latest CVS version). Portage would then try to install the older |
17 |
package B because it thinks it needs it to satisfy package A's |
18 |
dependencies. All package.provided does is tell portage "you may not see |
19 |
it in your database but cate-gory/packageb-x.y.z is installed". |
20 |
|
21 |
package.provided is potentially dangerous because portage is now basing |
22 |
its decisions on what you tell it is installed rather than what it knows |
23 |
is installed, you are overriding the normal dependency checks. If package |
24 |
A is incompatible with the later package B, portage won't know and |
25 |
problems may surface later. |
26 |
|
27 |
|
28 |
-- |
29 |
Neil Bothwick |
30 |
|
31 |
Isn't 'Criminal Lawyer' rather redundant? |