1 |
Le jeudi 01 avril 2010 à 03:18 -0700, Brian Harring a écrit : |
2 |
> On Thu, Apr 01, 2010 at 12:10:20PM +0200, Gilles Dartiguelongue wrote: |
3 |
> > jumping on the train here, but who said PM would not feed proper data to |
4 |
> > pkg_pretend so it would behave like the DEPEND were already built. Could |
5 |
> > some guy involved in a PM development tell us about how this would be |
6 |
> > handled ? |
7 |
> |
8 |
> Good idea, but not really viable. The only scenario where this would |
9 |
> work cleanly is in has_version checks which most of the time should be |
10 |
> blockers/deps anyways. |
11 |
|
12 |
That's indeed the only thing I was thinking of |
13 |
|
14 |
> Basically, you want the PM to lie to the ebuild in some fashion. |
15 |
> Since pkg_pretend is free form, it's effectively impossible to cover |
16 |
> the scenarios it could check on- consider checking the kernel |
17 |
> config/version, or checking the active jvm/python version. |
18 |
|
19 |
except the kernel will not change during the upgrade, unless you reboot |
20 |
in the middle of the upgrade but I would expect the PM to recompute |
21 |
pkg_pretend in resume. |
22 |
|
23 |
> Some of those can sort of be handled, but it requires a lot of custom |
24 |
> code (code that has to change as the tools involved change) to pull it |
25 |
> off. |
26 |
> |
27 |
> As said, good idea, but it was ruled out due to it being techically |
28 |
> infeasible considering the gains. |
29 |
|
30 |
Since I have little insight on the rest I will trust whatever decision |
31 |
has been taken. |
32 |
|
33 |
-- |
34 |
Gilles Dartiguelongue <eva@g.o> |
35 |
Gentoo |