| 1 |
On Wed, 24 Jul 2013 13:40:48 -0600 |
| 2 |
Ryan Hill <dirtyepic@g.o> wrote: |
| 3 |
> > Actually per PMS you are required to revbump (and therefore require |
| 4 |
> > upgrade on users' side) whenever you change the deps and don't |
| 5 |
> > expect to add a new version soon enough. Otherwise your changes |
| 6 |
> > don't get spread and users end up with never-ending blockers and |
| 7 |
> > stuff like that. |
| 8 |
> > |
| 9 |
> > Other thing is that Portage explicitly ignores PMS in this matter |
| 10 |
> > and uses dependencies from ebuilds rather than recorded ones. This |
| 11 |
> > is supposedly wrong, supposedly slow but allows us to be lazy. |
| 12 |
> |
| 13 |
> Thank god. That is insane. |
| 14 |
> |
| 15 |
> Let's not document that one in the manual. |
| 16 |
|
| 17 |
The issue's not as simple as one might initially think, and both ways |
| 18 |
have their drawbacks. |
| 19 |
|
| 20 |
The only drawback of "use dependencies at the time the package was |
| 21 |
installed" is that developers can't retroactively change dependencies |
| 22 |
without a revbump. |
| 23 |
|
| 24 |
The drawbacks of "use VDB" are: |
| 25 |
|
| 26 |
* That ebuilds can be updated without revbumps to have "changed" |
| 27 |
dependencies. The example that comes up most is pkg_prerm changes to |
| 28 |
use or stop using a foo-config type app. If a package mangler then |
| 29 |
uses the "changed" dependencies, it can lead to premature |
| 30 |
uninstallation of a foo-config that's needed to safely uninstall |
| 31 |
something. |
| 32 |
|
| 33 |
* That it assumes there's a one-to-one correspondence between |
| 34 |
"installed ebuild" and "installable ebuild". This means that whenever |
| 35 |
ebuild versions are cleaned up in the tree, suddenly the dependencies |
| 36 |
of your installed packages change. It gets even trickier when |
| 37 |
overlays and binaries are involved. |
| 38 |
|
| 39 |
* The way Portage does it doesn't work if there are := dependencies. |
| 40 |
|
| 41 |
So the tradeoff is between "require more revbumps" or "randomly broken |
| 42 |
dependency handling", and neither is ideal. Portage currently leans |
| 43 |
towards the latter, on the grounds that users expect broken |
| 44 |
dependencies and strange failures every now and again, but hate |
| 45 |
"wasting time" on "unnecessary" revbumps. |
| 46 |
|
| 47 |
-- |
| 48 |
Ciaran McCreesh |
Archives