FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-14-2009, 06:43 PM
Tomáš Chvátal
 
Default Live ebuilds management.

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).
 
Old 03-14-2009, 06:48 PM
Ciaran McCreesh
 
Default Live ebuilds management.

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
 
Old 03-14-2009, 06:51 PM
Avuton Olrich
 
Default Live ebuilds management.

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.
 
Old 03-14-2009, 06:59 PM
Avuton Olrich
 
Default Live ebuilds management.

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.
 

Thread Tools




All times are GMT. The time now is 11:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org