[gentoo-dev] Live ebuilds management.

[gentoo-dev] Live ebuilds management.

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

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=17db06c9cd310c1f97360e3ad2d45cb6b30386d3;hb=ef91eb936e50262e32ee8c71c2853cfdbbfe18a1

Cheers
Tomas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Live ebuilds management.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Live ebuilds management.

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Dne sobota 14 Březen 2009 20:32:52 Ciaran McCreesh napsal(a):
> 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.
Hm i try to crawl around if i find some time. Maybe i find them.
>
> 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

Well for git i am already parsing if the revision changed or not and based on 
that i log usefull informations for user :]

So i guess adding wrapper around remaining relevant phases is just bit coding 
around. I am sadly not sure how other scms behave and specialy it is sweet 
overhead in cvs as you say :]

But at least for git users it would be nice to have (fdo, kernel, various misc 
stuff).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Live ebuilds management.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On Sat, 14 Mar 2009 20:43:09 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> So i guess adding wrapper around remaining relevant phases is just
> bit coding around.

It's not. Not if you want to be able to do background fetches, not if
you want to be able to show the user at --pretend time what's going to
happen, and not if you want to give the user proper control of what
will happen.

Nor is this something that can be done as a hack without package manager
help -- you can't 'skip' a package from within a package, and even if
you could you can't know whether that's what the user wants (they might
be doing an emerge -e, for example).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Live ebuilds management.

[Avuton Olrich]

On Sat, Mar 14, 2009 at 11:32 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> 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.

> * 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.

By the way, update-live-ebuilds[1] gets around this by doing sha1sum
on certain parts of the CVS directory. CVS and TLA are the only
eclasses which this should be necessary. This, obviously, means a
update is done first and the hash is figured out afterwards, making it
rather limiting.

1. http://forums.gentoo.org/viewtopic-t-725867-start-0-postdays-0-postorder-asc-highlight-ule.html
-- 
avuton
--
|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

Re: [gentoo-dev] Live ebuilds management.

[Avuton Olrich]

On Sat, Mar 14, 2009 at 11:32 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> In terms of goals, [1] is what I'd consider to be an ideal list.

One thing I would personally add to the list is to somehow be able to
set certain packages not to update more than x often. There are some
packages which users care about which they'll want updated daily,
others they'll want daily, weekly or otherwise. For instance, if the
kde-svn overlay is on someone's system they may not want to update
kde-svn packages daily, but may want everything else updated daily.
-- 
avuton
--
|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.