| 1 |
On Wed, 19 Aug 2015, Alan McKinnon wrote: |
| 2 |
|
| 3 |
> On 19/08/2015 21:58, Alec Ten Harmsel wrote: |
| 4 |
> > On Wed, Aug 19, 2015 at 08:55:16PM +0100, Mick wrote: |
| 5 |
> >> On Wednesday 19 Aug 2015 10:28:48 Jeremi Piotrowski wrote: |
| 6 |
> >>> Smart live rebuild only deals with live ebuilds. How would it help in this |
| 7 |
> >>> case? |
| 8 |
> >> |
| 9 |
> >> Anyone cares to explain what is a "live ebuild"? |
| 10 |
> >> |
| 11 |
> >> Then I may be able to understand what @smart-live-rebuild may be useful for. |
| 12 |
> >> :-/ |
| 13 |
> >> |
| 14 |
> >> -- |
| 15 |
> >> Regards, |
| 16 |
> >> Mick |
| 17 |
> > |
| 18 |
> > A "live ebuild" is an ebuild that pulls the code to build straight from |
| 19 |
> > whatever version control the developers are using, so you always have |
| 20 |
> > the latest and greatest. |
| 21 |
> > |
| 22 |
> > Alec |
| 23 |
> > |
| 24 |
> |
| 25 |
> |
| 26 |
> they usually have version number -9999 |
| 27 |
> |
| 28 |
|
| 29 |
portage has no way of knowing if the repository the package comes from |
| 30 |
has been updated without fetching the sources and this is done during the |
| 31 |
merge process. So portage has no knowledge of the state of live-ebuild |
| 32 |
packages prior to starting a merge - it doesn't know if they have been |
| 33 |
updated upstream, so it does nothing to them during normal updates. |
| 34 |
|
| 35 |
To update them you can use the set @live-rebuild. But this causes live |
| 36 |
packages to be unconditionally rebuilt even if they haven't changed. |
| 37 |
|
| 38 |
Smart-live-rebuild deals with this by updating the repositories and then |
| 39 |
only re-emerging packages that have been changed. |
Archives