| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 26/07/14 11:22 AM, Ciaran McCreesh wrote: |
| 5 |
> |
| 6 |
> Let's start with the easiest issue: please point us all to the |
| 7 |
> place where you "proved" how dynamic dependencies still work in the |
| 8 |
> face of ebuild removals. Your solution to this problem will be of |
| 9 |
> great benefit to all of us. |
| 10 |
> |
| 11 |
|
| 12 |
This is something I personally don't understand. If an ebuild for a |
| 13 |
package installed on the system has been removed from the tree, but |
| 14 |
newer and/or older ebuilds exist in the tree, then the installed |
| 15 |
package can #1 only be trusted in accordance with the ebuild copy |
| 16 |
enbedded in VDB (that i get), BUT, #2 should be forced to either |
| 17 |
upgrade or downgrade so that it matches what *is* in the tree anyhow, |
| 18 |
and that's done via a standard ${PV} comparison that should happen |
| 19 |
regardless of whether static or dynamic deps methods are in place. |
| 20 |
|
| 21 |
IMO, if currently-installed versions of packages are satisfying |
| 22 |
dependencies after those packages have been removed from the tree, I |
| 23 |
don't see this as being particularly valid anyhow. Sure, end-users |
| 24 |
should be able to force this using masks or whatnot in the particular |
| 25 |
cases they need to do this, but i don't think this should be in any |
| 26 |
way a default behaviour, should it?? Ebuilds are removed for a reason... |
| 27 |
|
| 28 |
|
| 29 |
-----BEGIN PGP SIGNATURE----- |
| 30 |
Version: GnuPG v2 |
| 31 |
|
| 32 |
iF4EAREIAAYFAlPWXncACgkQ2ugaI38ACPBWLQEAp3sB8lfdZ8FYmXRsxNy6SlHE |
| 33 |
AR40+p+/x6J5+m4D618BAK4XKG64W92WFWne2rn3cDtdKuoQ+wwN2RBw066MoPJQ |
| 34 |
=TyGx |
| 35 |
-----END PGP SIGNATURE----- |
Archives