hi,
if you find your time would you mind pointing your eyes on bug 262010 [1].
There is interesting idea about loging usefull informations about repository
for further usage (that thing i find interesting and already implemented [2]).

But in comment 4 user ask about updates itself. If we have live package and
revision does not change it is pointless waste of resources to recompile it
usualy.

So i am asking if it is worth to implement some LIVE_FORCE_BUILD:bool where
user specify if he wants recompile the package or not and if LIVE_FORCE_BUILD
is set to false and nothing changes all relevant phases are skipped with
something like:
elog "Doing nothing because we are UP-TO-DATE already."
which might result in faster emerge @live-rebuild for example because not
every package is needed to be updated.

[1] - http://bugs.gentoo.org/show_bug.cgi?id=262010
[2] -
http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=blob;f=eclass/git.eclass;h=17db06c9cd310c1f97360e3ad2d45cb6b3038 6d3;hb=ef91eb936e50262e32ee8c71c2853cfdbbfe18a1

Cheers
Tomas

On Sat, 14 Mar 2009 20:22:16 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> But in comment 4 user ask about updates itself. If we have live
> package and revision does not change it is pointless waste of
> resources to recompile it usualy.

Doing this properly is an awful lot of work and a lot trickier than
initially apparent. There was a discussion in #gentoo-council about it
after the last meeting; unfortunately I don't have logs.

I see the solution as being done in four parts, one after another:

* Proper ordering for live packages. This is GLEP 54.

* Allowing installed SCM ebuilds to identify the revision with which
they were built. This isn't overly difficult, once you get around
things like CVS not really having a revision.

* Allowing SCM ebuilds to identify upfront, and potentially at
--pretend time, with which revision they will be built. This is the
hard part, especially if you want to be able to background fetch them.

* Allowing user overrides of revisions in a controlled manner.

In terms of goals, [1] is what I'd consider to be an ideal list.

Unfortunately, given the difficulty of getting even the first item on
the list implemented, I don't see this going anywhere any time soon for
Gentoo...

[1]: http://lists.exherbo.org/pipermail/exherbo-dev/2009-March/000409.html

--
Ciaran McCreesh