1 |
On Tue, Jul 29, 2014 at 3:33 AM, Peter Stuge <peter@×××××.se> wrote: |
2 |
> |
3 |
> Rich Freeman wrote: |
4 |
>> This is really the crux of these sorts of issues. It doesn't matter |
5 |
>> if dependencies are static or dynamic - if you hang onto orphans then |
6 |
>> you're going to have cruft in your vdb which is going to lead to |
7 |
>> blockers of some kind eventually. |
8 |
> |
9 |
> I think the vdb can and should be updated according to portage changes. |
10 |
> |
11 |
> Someone just needs to code it. ;) |
12 |
|
13 |
So, I'll agree that vdb should change when portage changes (and we |
14 |
should manage portage changes so that this can be done reliably), but |
15 |
we're talking about orphans here. Portage is only going to get one |
16 |
side of the story when dealing with an orphan. |
17 |
|
18 |
In your example of a package split the original package went away, and |
19 |
perhaps with some mechanism we could get portage to update all former |
20 |
dependencies to use both sides of the split. |
21 |
|
22 |
But, how about virtualization of a package? Your orphan depends on |
23 |
non-virtual udev, but now you want to install systemd which of course |
24 |
blocks udev. Maybe your package really does depend on the "real" udev |
25 |
(probably not a good example here - think ffmpeg instead perhaps), or |
26 |
maybe it can use the virtual. Just telling portage that the virtual |
27 |
replacement has been made is one problem, but figuring out whether to |
28 |
use it is going to be a wild guess for a PM. |
29 |
|
30 |
And there are likely other variations as well. |
31 |
|
32 |
Rich |