Dnia 2013-07-25, o godz. 17:07:00 Michael Palimaka napisał(a): > On 25/07/2013 05:17, Michał Górny wrote: > > Actually per PMS you are required to revbump (and therefore require > > upgrade on users' side) whenever you change the deps and don't expect > > to add a new version soon enough. > > Can you please provide a link/reference to that part? I am interested in > reading more about it. To be honest, I have no idea if that's worded at all since PMS doesn't cover vardb. I may have overused the term 'per PMS' then. However, this is what Brian & Ciaran (at least) were criticizing for some time. The idea is that when you build an ebuild, you are basically either creating a binary package or installing a package to the system (or both). Along with that, metadata is transferred from the ebuild to the package or vardb. With a proper design, you have two 'repos': one with ebuilds, and the other consisting purely of installed packages (vardb/system). What's important, per definition vardb is self-satisfactory. That is, dependencies of every installed package are supposed to be satisfied by installed packages purely. 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. -- Best regards, Michał Górny