| 1 |
Dnia 2013-07-25, o godz. 17:07:00 |
| 2 |
Michael Palimaka <kensington@g.o> napisał(a): |
| 3 |
|
| 4 |
> On 25/07/2013 05:17, Michał Górny wrote: |
| 5 |
> > Actually per PMS you are required to revbump (and therefore require |
| 6 |
> > upgrade on users' side) whenever you change the deps and don't expect |
| 7 |
> > to add a new version soon enough. |
| 8 |
> |
| 9 |
> Can you please provide a link/reference to that part? I am interested in |
| 10 |
> reading more about it. |
| 11 |
|
| 12 |
To be honest, I have no idea if that's worded at all since PMS doesn't |
| 13 |
cover vardb. I may have overused the term 'per PMS' then. |
| 14 |
|
| 15 |
However, this is what Brian & Ciaran (at least) were criticizing for |
| 16 |
some time. The idea is that when you build an ebuild, you are basically |
| 17 |
either creating a binary package or installing a package to the system |
| 18 |
(or both). Along with that, metadata is transferred from the ebuild to |
| 19 |
the package or vardb. |
| 20 |
|
| 21 |
With a proper design, you have two 'repos': one with ebuilds, |
| 22 |
and the other consisting purely of installed packages (vardb/system). |
| 23 |
What's important, per definition vardb is self-satisfactory. That is, |
| 24 |
dependencies of every installed package are supposed to be satisfied by |
| 25 |
installed packages purely. |
| 26 |
|
| 27 |
Now, what portage does is implicitly applying _some_ of the metadata |
| 28 |
from the ebuild tree to vardb without rebuilding the package. In some |
| 29 |
cases. As an effect, vardb is no longer self-satisfactory, |
| 30 |
and represents something between the package that was built |
| 31 |
and the current ebuild. |
| 32 |
|
| 33 |
Ciaran has already elaborated a bit on the potential issues. It gets |
| 34 |
most dangerous when you create some meaningful changes without |
| 35 |
a revbump. I'll give you a simple example that I can think of. |
| 36 |
|
| 37 |
Say, you fix a semi-build-time issue of linking against unnecessary |
| 38 |
dep. Users who build the ebuild from now on benefit by having less |
| 39 |
deps. The dep is less problematic than rebuilding the package, so users |
| 40 |
who built it before prefer to wait for next version. |
| 41 |
|
| 42 |
But in this case, portage may implicitly update the deps from ebuild |
| 43 |
without rebuilding it. This means that users who still link against |
| 44 |
the dep, may end up with the dep removed and program broken. |
| 45 |
|
| 46 |
-- |
| 47 |
Best regards, |
| 48 |
Michał Górny |
Archives