I just remembered something interesting:
cave resolve '!app-editors/vim:0::/'
will force a reinstall vim if it's installed, and will do nothing
otherwise. Thus, if you want to reinstall things dependent upon a
package, you can do:
cave resolve $(cave print-dependent-ids vim::/ -f '!=%F ' )
and so it wouldn't be hard to make:
cave resolve --reinstall-dependents-of vim
(except that we've run out of short option letters), but that's not the
interesting bit.
Some of you think you have packages that, when reinstalled or upgraded,
require other packages to be reinstalled afterwards. Maybe we just need
some fancy syntax to map onto this mechanism...
DEPENDENCIES="
breaks:
dev-libs/foo
dev-libs/bar
"
or something... Which could be used to create installed-only blockers,
and would enforce "foo after me" style ordering.
So the questions are:
Can you list the packages that would get broken in the package being
upgraded?
If you can't, would allowing sets in repositories and in DEPENDENCIES
be sufficient to make it work? So you'd do:
DEPENDENCIES="
breaks:
haskell-libraries
"
or something.
Does upgrading something always break its dependents? What about
reinstalling? Or are the rules more complicated than that? Do we need
something like:
DEPENDENCIES="
breaks:
(
dev-libs/foo
dev-libs/bar
) [[ *if-replacing = [ <1.23 ] ]]
"
--
Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
