| 1 |
On Fri, 1 Aug 2014 10:00:34 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
> The thing is, giving up things like @preserved-rebuild seems a bit |
| 4 |
> like threatening to kill kittens until people wake up and clean their |
| 5 |
> code. We're talking about ripping out 80% solutions in favor of 20% |
| 6 |
> solutions in order to motivate ourselves to build 100% solutions. |
| 7 |
|
| 8 |
preserved-rebuild isn't an 80% solution. It's a 90% problem. |
| 9 |
|
| 10 |
> > * They suddenly stop working if an ebuild is removed. |
| 11 |
> |
| 12 |
> This is only the result of the current implementation, which begins |
| 13 |
> taking into account dynamic dependencies but then doesn't update VDB. |
| 14 |
> I think a better approach is that once a dynamic dependency is used, |
| 15 |
> the VDB should be updated to reflect it. |
| 16 |
|
| 17 |
This only fixes the special case where the change is "seen". |
| 18 |
|
| 19 |
> That is my concern with this kind of approach. It results in a much |
| 20 |
> cleaner data model, but it doesn't actually fix the reality that |
| 21 |
> things break when they have wrong dependencies. |
| 22 |
|
| 23 |
Things are already broken if developers are specifying wrong |
| 24 |
dependencies. We have bigger problems if your assertion is that |
| 25 |
developers getting dependencies wrong is so common that revbumping to |
| 26 |
fix them would affect users. |
| 27 |
|
| 28 |
> > * They don't work with binary packages. |
| 29 |
> > |
| 30 |
> |
| 31 |
> Sort-of. This is really just the VDB updating problem again, though |
| 32 |
> complicated by the fact that your binary package contains its own VDB. |
| 33 |
> It might be fixable at time of merging it, and if the original ebuild |
| 34 |
> isn't around at that time then you're back to the static dep model |
| 35 |
> which either breaks or not in the same way it would have before. |
| 36 |
|
| 37 |
Static dependencies only break if a developer screws up, which should |
| 38 |
be rare. Dynamic dependencies break under normal operation. |
| 39 |
|
| 40 |
> > * They're utterly incompatible with subslot deps. |
| 41 |
> |
| 42 |
> I get that they aren't implemented with subslot deps. I'm not quite |
| 43 |
> sure why they can't be. When a new dep shows up, record the subslot |
| 44 |
> used to satisfy it when it is first satisifed. |
| 45 |
|
| 46 |
There's no simple mapping in the "complex mess of || dependencies" case. |
| 47 |
|
| 48 |
> > * Someone adds selinux support to foo. Then a new bar starts |
| 49 |
> > requiring foo[selinux]. The user hasn't rebuilt their foo to get |
| 50 |
> > selinux support, but the dependency is still met, thanks to dynamic |
| 51 |
> > dependencies. |
| 52 |
> |
| 53 |
> I don't see this as having anything to do with dynamic dependencies. |
| 54 |
> If foo was built without selinux, then it wouldn't meet the |
| 55 |
> dependency. USE changes can't be assumed as not impacting the |
| 56 |
> installed files - I doubt this would be true in even a small minority |
| 57 |
> of cases. |
| 58 |
|
| 59 |
I included this one because it was presented as a "feature" of dynamic |
| 60 |
dependencies earlier in the discussion. |
| 61 |
|
| 62 |
> I'm not entirely sure if this is just an implementation issue. |
| 63 |
|
| 64 |
It isn't. It's a design flaw. |
| 65 |
|
| 66 |
-- |
| 67 |
Ciaran McCreesh |
Archives