| 1 |
On Mon, 28 Jul 2014 10:30:15 -0400 |
| 2 |
Ian Stakenvicius <axs@g.o> wrote: |
| 3 |
> On 26/07/14 11:22 AM, Ciaran McCreesh wrote: |
| 4 |
> > |
| 5 |
> > Let's start with the easiest issue: please point us all to the |
| 6 |
> > place where you "proved" how dynamic dependencies still work in the |
| 7 |
> > face of ebuild removals. Your solution to this problem will be of |
| 8 |
> > great benefit to all of us. |
| 9 |
> > |
| 10 |
> |
| 11 |
> This is something I personally don't understand. If an ebuild for a |
| 12 |
> package installed on the system has been removed from the tree, but |
| 13 |
> newer and/or older ebuilds exist in the tree, then the installed |
| 14 |
> package can #1 only be trusted in accordance with the ebuild copy |
| 15 |
> enbedded in VDB (that i get), BUT, #2 should be forced to either |
| 16 |
> upgrade or downgrade so that it matches what *is* in the tree anyhow, |
| 17 |
> and that's done via a standard ${PV} comparison that should happen |
| 18 |
> regardless of whether static or dynamic deps methods are in place. |
| 19 |
|
| 20 |
But you can't run pkg_prerm unless a package's dependencies are |
| 21 |
satisfied. How do you know what those dependencies are, if you don't |
| 22 |
use VDB and if the ebuild isn't there? |
| 23 |
|
| 24 |
(This is a real issue: see the botched ruby-config switch.) |
| 25 |
|
| 26 |
-- |
| 27 |
Ciaran McCreesh |
Archives