Dnia 2013-07-25, o godz. 17:07:00
Michael Palimaka <kensing...@gentoo.org> 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

Attachment: signature.asc
Description: PGP signature

Reply via email to