| 1 |
Ühel kenal päeval, E, 13.12.2021 kell 10:19, kirjutas Marek Szuba: |
| 2 |
> On 2021-12-09 15:04, Michał Górny wrote: |
| 3 |
> |
| 4 |
> > Why do you need to use random name in the first place? We have |
| 5 |
> > full |
| 6 |
> > control over T, so why not just hardcode a good name? |
| 7 |
> |
| 8 |
> Having discussed the matter with eclass maintainers on IRC, they are |
| 9 |
> not |
| 10 |
> entirely sure whether using a static name in this context is entirely |
| 11 |
> safe. There were also concerns about making this change too |
| 12 |
> aggressive |
| 13 |
> given it affects all supported EAPIs. Therefore, we have decided to |
| 14 |
> play |
| 15 |
> it safe and stick as closely to old behaviour as possible, at least |
| 16 |
> for now. |
| 17 |
> |
| 18 |
> Anyway, merged a moment ago. |
| 19 |
|
| 20 |
Actually I kind of preferred a static name over straight mktemp, |
| 21 |
because emktemp supported other cases than a pure mktemp usage does. |
| 22 |
But I don't know if it could ever clash things in some weird |
| 23 |
situations. I think they won't, but I don't know if PMS guarantees that |
| 24 |
or just happens how portage works right now (e.g. the postrm currently |
| 25 |
happening in a separate ._unmerge directory path for $T; multilib |
| 26 |
postinst happening sequentially, etc). |
| 27 |
|
| 28 |
Thinking it through again a bit, straight mktemp can't be worse than a |
| 29 |
static name anyways (provided mktemp exists, which emktemp handled..), |
| 30 |
so we're good there, but provided you or someone thinks through the |
| 31 |
corner-cases, I'm in favor of a static name if it doesn't have any |
| 32 |
trouble. |
| 33 |
|
| 34 |
|
| 35 |
Mart |
Archives