public inbox for gentoo-council@lists.gentoo.org
 help / color / mirror / Atom feed
From: Roy Bamford <neddyseagoon@gentoo.org>
To: gentoo-council@lists.gentoo.org
Subject: Re: [gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal
Date: Mon, 09 Mar 2009 23:29:29 +0000	[thread overview]
Message-ID: <1236641374.19203.0@spike> (raw)
In-Reply-To: <20090309224725.GA11724@dodo.hsd1.nj.comcast.net> (from gentoofan23@gentoo.org on Mon Mar  9 22:47:25 2009)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.03.09 22:47, Thomas Anderson wrote:
> Hi,
> 
>     Attached is my comparison of the two proposals for live sources.
>     Sorry about getting it out late, I had to get ahold of a number 
> of
>     people to finish writing it up.
> 
> Cheers,
> Thomas
> -- 
> ---------
> Thomas Anderson
> Gentoo Developer
> /////////
> Areas of responsibility:
> AMD64, Secretary to the Gentoo Council
> ---------
> 
> 

- ------quoted attachment "glep54comp.txt"------
[snip]
> 
>     One important issue is what happens in the following
>     scenario:
>     	1) world update starts at 20090301@2200hrs.
> 	2) this particular update involves 100 packages so it takes
> quite
> 	along time
> 	3) The _live package is not reached until 20090302 at 1AM.
> 
>      Is the package installed as 20090301 or 20090302?
> 
[snip]

> 
Thomas,

Live has to expand to the date when the sources were fetched, otherwise 
its not 'live' by definition.
As an illustration, I install KDE 4.2 on my 25MHz 486DX with 64Mb RAM.
During the time it takes to build, 'live' is likely to have changed 
several times.

How do you handle prefetching of sources, or do you forbid 
prefetching ?
Live infers you fetch the sources at the time you need to build them 
and do the live expansion at that time. Without that you don't know how 
old your live version is.

live can change several times a day. With only one day resolution, how 
do you handle that?

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkm1pl4ACgkQTE4/y7nJvatrEACg6JF/DcOjL65KJG7XL6L1AzIx
WToAoL+JgmILR6rsxNn4G/jhnk+thcGv
=g/qP
-----END PGP SIGNATURE-----




  reply	other threads:[~2009-03-09 23:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09 22:47 [gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal Thomas Anderson
2009-03-09 23:29 ` Roy Bamford [this message]
2009-03-10  1:15   ` Thomas Anderson
2009-03-10  1:53   ` Luca Barbato
2009-03-10  2:26 ` Luca Barbato
2009-03-10 14:00   ` Thomas Anderson
2009-03-10 14:39     ` Thomas Anderson
2009-03-10 14:56     ` Luca Barbato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1236641374.19203.0@spike \
    --to=neddyseagoon@gentoo.org \
    --cc=gentoo-council@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox