1 |
Dnia 2014-07-21, o godz. 21:34:10 |
2 |
Alexandre Rostovtsev <tetromino@g.o> napisał(a): |
3 |
|
4 |
> On Mon, 2014-07-21 at 22:56 +0200, Michał Górny wrote: |
5 |
> > Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps |
6 |
> > are a pipe dream. You can't implement them properly, so we're using |
7 |
> > half-working implementation as an excuse to be lazy. |
8 |
> |
9 |
> Why not adapt the updates mechanism for modifying rdepends? Perhaps |
10 |
> something like |
11 |
> |
12 |
> rdepends-add foo-bar/blah-3.14 "wombat? ( >=dev-libs/wombat-1.0 )" |
13 |
> |
14 |
> This would give the package manager all the benefits of static dep |
15 |
> resolution while allowing us to dynamically make simple changes (like |
16 |
> adding a missing dependency to an ebuild) without forcing users to |
17 |
> rebuild the package. |
18 |
|
19 |
At the moment updates are stateless. In other words, PM has no idea if |
20 |
the update has been applied or not, and the update should be defined so |
21 |
that it can't be applied multiple times. |
22 |
|
23 |
IOW, if you do a pkgmove via updates, the originating package ebuild |
24 |
must no longer exist so that the update can be only applied once. If |
25 |
you do a slotmove, the originating slot must no longer be used |
26 |
in affected ebuilds. |
27 |
|
28 |
Now, with dependency updates you lack this guarantee. Package manager |
29 |
can add the dependency... and then add it again... and again... |
30 |
and again. It could supposedly try to match dependencies and find out |
31 |
whether a particular dependency has been added already but that sounds |
32 |
like something that could easily cause issues in the future. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |