Re: Some easy sugestions to implement, I hope

>I'm not following.

Ok, I'm gonna try and explain everything better (->long
email :S). I'm 
having this problem with the emerge step on the livecd
stage1 target.

The thing is, it tries to emerge lots of packages and due to
problems with 
portage mostly, it results in a interrupted build. From
there I can resume 
catalyst, but unfortunately it won't allow me to go back and
unmerge/rebuild 
packages. It also doesn't allow me to -quickly- try new
emerge setups like 
doing emerge --pretend on some packages (with new use
flags), see what's 
pulling what and how.

The only options I have is to either go on and emerge more,
or do it all 
over again after changing the spec. From what is written on
the website, 
using something like tinderbox to build a livecd would be
helpful, but from 
what I read you can only use it for testing, not to use in a
livecd stage2.

The ideal would be to have total control of the emerge step
therefore easily 
avoiding circular dependencies, emerge blocks of packages at
a time, easily 
find and remove unnecessary packages, etc. Well, at least as
easy as in our 
system.

I conclude from

>It does take Release Engineering upwards of a month to
stabilize any
>given snapshot to build a release.  Maybe there's a
reason for that.  ;]


this is a problem for everyone, so there is no current way
to go around it 
is there? (actual question, not rhetoric :P)

Wouldn't it be great if you could just get in and do this
small step 
yourself as an option? One could always do this only to
obtain a bunch of 
built packages and -then- do a clean build right?

So my question is, how do you build the release cd's? You do
try and error 
on ebuilds like I do, and write portage overlays? Would it
be bad if you 
could enter the cd and manually emerge stuff yourself,
solving problems at 
the moment instead of building all over again everytime
portage complains? 
Is there a problem with the current catalyst implementation
that would make 
this hard to code?

>Making it "easy", and thereby encouraging
people, to poke around in the 
>caches is the absolute last thing I want to do.

Ok instead of calling it --chroot, call it --pretend.
Everything a user did 
would be erased. No problems with touching the ccas (it
forces a clean 
build) and one could still build pkg's and "play"
with emerge.

Phew .
I understand you must be full of work with the new release,
reply 
anytime, and thanks for the help.

Cheers

____________________________________________________________
_____
Express yourself instantly with MSN Messenger! Download
today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471
ave/direct/01/

-- 
gentoo-catalystgentoo.org mailing list

Nelson Batalha wrote:
> The ideal would be to have total control of the emerge
step therefore 
> easily avoiding circular dependencies, emerge blocks of
packages at a 
> time, easily find and remove unnecessary packages, etc.
Well, at least 
> as easy as in our system.

Catalyst builds are not supposed to be *interactive*. If you
are hitting these 
problems, you're doing something wrong and/or stupid. Most
of the time, getting 
blockers is a result of using an old stage3 seed to build a
livecd with a newer 
snapshot.

-- 
Andrew Gaffney                            http://dev.gentoo.or
g/~agaffney/
Gentoo Linux Developer                                  
Installer Project
-- 
gentoo-catalystgentoo.org mailing list

On Thu, 2007-03-29 at 17:33 +0000, Nelson Batalha wrote:
> The ideal would be to have total control of the emerge
step therefore easily 
> avoiding circular dependencies, emerge blocks of
packages at a time, easily 
> find and remove unnecessary packages, etc. Well, at
least as easy as in our 
> system.

No.  The ideal is to have a perfectly working snapshot with
no errors in
it.  ;]

> I conclude from
> 
> >It does take Release Engineering upwards of a month
to stabilize any
> >given snapshot to build a release.  Maybe there's a
reason for that.  ;]
> 
> 
> this is a problem for everyone, so there is no current
way to go around it 
> is there? (actual question, not rhetoric :P)

Yes and no.  We take a given snapshot and modify it to suit
our needs.

> Wouldn't it be great if you could just get in and do
this small step 
> yourself as an option? One could always do this only to
obtain a bunch of 
> built packages and -then- do a clean build right?

No.

Gentoo releases *must* build 100% with *no* caches and *no*
manual
intervention with the release snapshot.  There are no
exceptions.
Because Release Engineering has 0 need for the functionality
you've
asked for, it isn't likely it would ever be included.

> So my question is, how do you build the release cd's?
You do try and error 
> on ebuilds like I do, and write portage overlays? Would
it be bad if you 
> could enter the cd and manually emerge stuff yourself,
solving problems at 
> the moment instead of building all over again everytime
portage complains? 

No.  We modify the snapshot.  We do massive amounts of
testing.

That's pretty much it.

> Is there a problem with the current catalyst
implementation that would make 
> this hard to code?

Hard?  Not necessarily.

I just don't feel like doing it since it's nothing we would
ever use.
Catalyst *is* first and foremost Gentoo's release-building
tool.

> >Making it "easy", and thereby encouraging
people, to poke around in the 
> >caches is the absolute last thing I want to do.
> 
> Ok instead of calling it --chroot, call it --pretend.
Everything a user did 
> would be erased. No problems with touching the ccas (it
forces a clean 
> build) and one could still build pkg's and
"play" with emerge.

We don't *want* people building packages.  We don't *want*
people
touching *anything* within the catalyst build.  The goal is
100%
non-interactive.  Anything else is a bug and the *bug* needs
to be
fixed, not worked around.

> Phew . I
understand you must be full of work with the new release,
reply 
> anytime, and thanks for the help.

I'm replying from a "Chili's" in the George Bush
International Airport
in Houston, Texas as I'm on my way to California for a job
interview.
You can't say I'm not dedicated... :P

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation