Michael Orlitzky <m...@gentoo.org> wrote: > What's happening is that the PM is using the metadata from the installed > version of the package, rather than the ninja-edited metadata in the > repo (how would it know which ebuilds were edited meaningfully?).
The question is easy to answer: It is reasonable to assume that the repository metadata is correct and more up-to-date than the metadata of the installed version. But the PM would need to be smart enough to interpret subslot-deps correctly and merge that from the data of installed packages in a clever way. > That's completely legal according to the PMS, and also the > smart thing to do: s/smart/dumb/, but necessary for a dumb PM. > sourcing a few thousand lines of bash *just in case* there was an > important change in some ebuild is a huge waste of users' time. That's wrong: The metadata has to be (re)generated anyway, independent of whether this is a revision bump or just a modification. For most syncing methods the bash sourcing does not happen on the user's machine, and on those machines where the metadata is actually calculated, there are checksums and timestamps used to minimize the effort. From this perspective there is no difference between a modification or a revision bump. > Developers have an easy way to signal that there was an important > change: to bump the "r" number at the end of the ebuild. That's why it was decided to do it this way instead of requiring a smarter PM. Instead of putting some smart logic into the PM (which in case of portage was not fully implemented and in case of other package managers not at all), the decision was to force recompilations for every user and every tiny dependency change. > One developer makes a change, and it saves > thousands of users each a lot of time. ... costs thousands of users a lot of compilation time, although the recompilation is completely pointless for each of them, but done only to keep the PM simpler.
