On 28 July 2013 21:11, Michał Górny <[email protected]> wrote: > Now, what portage does is implicitly applying _some_ of the metadata > from the ebuild tree to vardb without rebuilding the package. In some > cases. As an effect, vardb is no longer self-satisfactory, > and represents something between the package that was built > and the current ebuild. > > Ciaran has already elaborated a bit on the potential issues. It gets > most dangerous when you create some meaningful changes without > a revbump. I'll give you a simple example that I can think of. > > Say, you fix a semi-build-time issue of linking against unnecessary > dep. Users who build the ebuild from now on benefit by having less > deps. The dep is less problematic than rebuilding the package, so users > who built it before prefer to wait for next version. > > But in this case, portage may implicitly update the deps from ebuild > without rebuilding it. This means that users who still link against > the dep, may end up with the dep removed and program broken.
If there was a portage feature of some kind that triggered a rebuild when /var/db/* deps mismatched ebuild deps, I'd use that ( similar to how you can trigger a rebuild when USE changes ) I'm one of those people who doesn't mind installing the same thing a million times a week =) -- Kent
