| 1 |
Dnia 2014-06-02, o godz. 15:47:04 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> napisał(a): |
| 3 |
|
| 4 |
> On Mon, 2 Jun 2014 11:42:07 +0200 |
| 5 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 6 |
> > This topic was already discussed in -dev some time ago [1], but went |
| 7 |
> > nowhere at the time. Now it came up again in bug 469210 [2]. |
| 8 |
> > (Ironically, checking for a particular kernel configuration is the |
| 9 |
> > example mentioned in the spec for pkg_pretend.) |
| 10 |
> |
| 11 |
> That's not ironic! It's not the spec's fault that people write lousy |
| 12 |
> eclasses. |
| 13 |
|
| 14 |
It is the spec's fault when it sets stupid and mismatched |
| 15 |
requirements. As long as we don't restrict pkg_* phases from calling |
| 16 |
external tools, prohibiting writes to temporary directory is just |
| 17 |
pointless. Every semi-sane system has a writable temporary directory |
| 18 |
that can be used freely by random programs, and so shall ebuild |
| 19 |
environment have. |
| 20 |
|
| 21 |
As for pkg_pretend(), I don't have a strong opinion whether it should |
| 22 |
be added to use external tools. However, prohibiting that would limit |
| 23 |
its use a lot. As for remaining pkg_*() phases, I think such |
| 24 |
prohibition would simply make the phases purposeless. |
| 25 |
|
| 26 |
As for ${T}, I consider it simply a convenient directory which ebuild |
| 27 |
can use for temporary files without needing to care about unique names |
| 28 |
and cleaning up afterwards. Prohibiting writes there during |
| 29 |
pkg_pretend() would be a minor inconvenience but may save the effort of |
| 30 |
preparing a separate temporary directory before build/install starts. |
| 31 |
However, I don't think the confusion caused by it outweighs the benefit. |
| 32 |
|
| 33 |
-- |
| 34 |
Best regards, |
| 35 |
Michał Górny |
Archives