| 1 |
On Thu, 2007-03-29 at 17:33 +0000, Nelson Batalha wrote: |
| 2 |
> The ideal would be to have total control of the emerge step therefore easily |
| 3 |
> avoiding circular dependencies, emerge blocks of packages at a time, easily |
| 4 |
> find and remove unnecessary packages, etc. Well, at least as easy as in our |
| 5 |
> system. |
| 6 |
|
| 7 |
No. The ideal is to have a perfectly working snapshot with no errors in |
| 8 |
it. ;] |
| 9 |
|
| 10 |
> I conclude from |
| 11 |
> |
| 12 |
> >It does take Release Engineering upwards of a month to stabilize any |
| 13 |
> >given snapshot to build a release. Maybe there's a reason for that. ;] |
| 14 |
> |
| 15 |
> |
| 16 |
> this is a problem for everyone, so there is no current way to go around it |
| 17 |
> is there? (actual question, not rhetoric :P) |
| 18 |
|
| 19 |
Yes and no. We take a given snapshot and modify it to suit our needs. |
| 20 |
|
| 21 |
> Wouldn't it be great if you could just get in and do this small step |
| 22 |
> yourself as an option? One could always do this only to obtain a bunch of |
| 23 |
> built packages and -then- do a clean build right? |
| 24 |
|
| 25 |
No. |
| 26 |
|
| 27 |
Gentoo releases *must* build 100% with *no* caches and *no* manual |
| 28 |
intervention with the release snapshot. There are no exceptions. |
| 29 |
Because Release Engineering has 0 need for the functionality you've |
| 30 |
asked for, it isn't likely it would ever be included. |
| 31 |
|
| 32 |
> So my question is, how do you build the release cd's? You do try and error |
| 33 |
> on ebuilds like I do, and write portage overlays? Would it be bad if you |
| 34 |
> could enter the cd and manually emerge stuff yourself, solving problems at |
| 35 |
> the moment instead of building all over again everytime portage complains? |
| 36 |
|
| 37 |
No. We modify the snapshot. We do massive amounts of testing. |
| 38 |
|
| 39 |
That's pretty much it. |
| 40 |
|
| 41 |
> Is there a problem with the current catalyst implementation that would make |
| 42 |
> this hard to code? |
| 43 |
|
| 44 |
Hard? Not necessarily. |
| 45 |
|
| 46 |
I just don't feel like doing it since it's nothing we would ever use. |
| 47 |
Catalyst *is* first and foremost Gentoo's release-building tool. |
| 48 |
|
| 49 |
> >Making it "easy", and thereby encouraging people, to poke around in the |
| 50 |
> >caches is the absolute last thing I want to do. |
| 51 |
> |
| 52 |
> Ok instead of calling it --chroot, call it --pretend. Everything a user did |
| 53 |
> would be erased. No problems with touching the ccas (it forces a clean |
| 54 |
> build) and one could still build pkg's and "play" with emerge. |
| 55 |
|
| 56 |
We don't *want* people building packages. We don't *want* people |
| 57 |
touching *anything* within the catalyst build. The goal is 100% |
| 58 |
non-interactive. Anything else is a bug and the *bug* needs to be |
| 59 |
fixed, not worked around. |
| 60 |
|
| 61 |
> Phew :). I understand you must be full of work with the new release, reply |
| 62 |
> anytime, and thanks for the help. |
| 63 |
|
| 64 |
I'm replying from a "Chili's" in the George Bush International Airport |
| 65 |
in Houston, Texas as I'm on my way to California for a job interview. |
| 66 |
You can't say I'm not dedicated... :P |
| 67 |
|
| 68 |
-- |
| 69 |
Chris Gianelloni |
| 70 |
Release Engineering Strategic Lead |
| 71 |
Alpha/AMD64/x86 Architecture Teams |
| 72 |
Games Developer/Council Member/Foundation Trustee |
| 73 |
Gentoo Foundation |
Archives