| 1 |
On Wednesday 06 August 2008 07:37:26 Joe Peterson wrote: |
| 2 |
> You are trying to say it's a 'live' ebuild (i.e. it gets the sources from a |
| 3 |
> live source) - that's all. The locking issues are a technical detail |
| 4 |
|
| 5 |
No, the locking issues are the whole point. There are other reasons to want |
| 6 |
the package manager know that an ebuild is live, yes, but they're fairly |
| 7 |
independent of the locking and so should be indicated separately. |
| 8 |
|
| 9 |
Consider what happens if/when we move the scm eclasses to do their own |
| 10 |
locking, for example: the ebuilds using them are still "live", but the |
| 11 |
mutually-exclusive unpack behaviour on the package manager side is no longer |
| 12 |
necessary or desirable. We can't just drop the behaviour from the package |
| 13 |
manager entirely at that point, because not all the eclasses will necessarily |
| 14 |
be updated at the same time (especially ones in overlays). |
| 15 |
|
| 16 |
On the other hand, people sometimes use the scm eclasses to fetch a particular |
| 17 |
revision, rather than "the latest". Ebuilds doing this still need the |
| 18 |
special parallelism handling, but they shouldn't be handled as "live" in |
| 19 |
other ways (such as automatic periodic rebuilds). |
Archives