chrome://messenger/locale/messengercompose/composeMsgs.properties: > Hi all, > > I've been busy for the past month or two, busy updating some of my > systems. In particular, the Yeeloong I have, hasn't seen attention in a > very long time. Soon as I update one part however, I find some swath of > packages break because of a soname change, anything Python-related stops > working because of a move from Python 2.6 to 2.7, or Perl gets updated. > > Currently we have three packages that handle this separately: > - revdep-rebuild (handles packages broken by soname changes, etc) > - python-updater (handles Python module rebuilds after upgrading Python) > - perl-cleaner (handles Perl module rebuilds after upgrading Perl)
I am thinking about a solution for those similar to current ruby idea and already implemented for cross-compilation in my multilib-portage branch of portage. The very short version: Set the needed details in the ebuilds, where needed, in case of revdep-rebuild, either adjust the SLOT var for each change requiring a rebuild of depending packages or using some new var, e.g. API_SLOT for this. Ebuilds depending on packages like python or perl should define the range of versions they support. Now portage generates a (use_expanded) list of USE flags for depending packages, e.g. for a package depending on python-2.6 and 2.7 it adds something like PYTHON_DEPEND="pyhon26 python27" to the list of USE flags. If there is only one dependency installed (like perl or changing libs), this could be a hidden USE flag. When the dependency is now updated, the USE flags will change, so in case of portage, a --newuse will catch those changes and shows those packages in the list of packages, that need to be emerged again. In case of slotted dependencies (like python, ruby or php), this would also allow the user to define per package, if he wants support for one or more slots of e.g. python.
signature.asc
Description: OpenPGP digital signature
