Re: [gentoo-catalyst] Couple of questions

[Mikey]

On Thursday 15 December 2005 07:34, Chris Gianelloni spammed:

> It is a bug in the snapshot/tree, as I stated in bug #115445.  I'm
> almost getting tired of explaining things seeing as how I have to do it
> multiple times.  Rather than me repeating myself, please read each
> message a few times instead? ;P

> know will not work as expected.  We are not stupid.  We have been
> working with portage and Gentoo for a long time and know what is and is
> not possible quite well by now.

As I am tired of repeating over and over that something is wrong with the 
stage1 target and all you seem to be able to do is blame me.  It only took 
me 5 freaking times to explain something was wrong.  So hey, you are not 
the only one who gets tired of repeating shit to thick headed people.  My 
snapshot version was right there in the spec files I posted, a simple 20 
minute test on your part would have confirmed the bug.  Apparently you 
portage people are not as smart as you would like me to believe, portage 
has its share of bugs and rarely behaves consistently.  I have been 
compiling linux from source for over 12 years, I happen to know a little 
bit about what I am talking about as well.  Probably not as much as you 
know about gentoo, but hey, I can recognize an obvious glaring problem when 
I see it.  

If you would have looked at what I posted in my bug report you would find a 
myriad of bugs.  Catalyst let me do things it is not supposed to do, like 
use a subarch during stage1 when it shouldn't.  Emerge told you it was 
going to install packages in a certain order, yet it didn't (not your bug).  
For some reason, baselayout was missing from the packages that were going 
to be installed, even though catalyst asked for it to be installed.  You 
indicate that usage of an envscript in catalyst.conf is normal usage, but 
fail to inform the user NOT to use USE flags in there or it will break 
something (that should be handled by catalyst).  You tell me catalyst is 
designed to not allow customization in the lower stages, then tell me the 
bug is invalid because I tried customization in lower stages.

But hey, I am sure it is a winning strategy to just treat all of your 
debuggers like they are idiots.

> Because making changes outside of the scope of the profile is broken.
> It produces an inconsistent stage, since the USE flags passed via an
> envscript *never* see the inside of make.conf, giving you a stage that
> *will not* behave as you expect it to.  Why leave this option available
> when it is *obviously* misunderstood and causes errors?  You have proven
> here exactly *why* the option is not there.

Gee, listen to what you are saying.  Using USE flags in stage2 and beyond is 
broken and produces inconsistent stages.  I would say that is a major 
problem that needs to be fixed before anything else, considering it is the 
most basic functionality that sets gentoo apart from all other linux 
distributions.  Stage2 ignores improper use flags via bootstrap.sh, stage3 
should be able to handle whatever use flag you throw at it, portage itself 
should be able to handle that.  So what is the problem with letting 
catalyst generate the use flags and put them into the make.conf right along 
with the cflags, mirrors, etc?  Don't worry, it is a rhetorical question.

> > nls, userlocales, nptl, nptlonly, multilib I think, and runs with
> > USE="-* build bootstrap allowed_flags", so why the restriction from
> > using nptl and
>
> There is no such restriction, as stated over and over and over and over
> again.  Use a profile to make these changes.

I see, using USE flags in the profile is not broken, letting the user 
specify USE flags anywhere else is.  Encouraging users to dork around with 
the profile is a good idea, set USE flags bad idea.  Brilliant.  
Particularly when you consider the fact that you can build "safe" USE flags 
into catalyst just like you build in "safe" cflags.  Which, by the way, are 
deprecated for gcc 3.4.4...

> No, you're being dense, rather.  I have explained it.  You just seem to
> dislike my answer.  Stages 2 and 3 must match the profile or they will
> not install properly in all cases.  Period.

Then something needs to be fixed, because the underlying process is broken.  
It needs to be the USE flags that match, it shouldn't matter where they 
come from.  Catalyst is not producing consistent results right now in spite 
of locking it down to the profile.  Locking catalyst down to extremely 
narrow functionality because portage might break at any moment is a shame, 
because it is a great tool.

But I just don't buy your explanation, USE flags are calculated the same way 
regardless of where you put them, in the profile or the environment.  The 
precedence might change, but they are still calculated the same way.  If I 
create a profile and take out nls, catalyst should handle it the exact same 
way as if I stuck it in the environment....

> Then I wouldn't accept them.  Catalyst is modular.  You're more than
> welcome to replace any of the scripts to do things the way you want

I don't think it is catalyst that is broken, but catalyst can be used to 
insure consistent results.  Simple things like install the toolchain in the 
proper order instead of using multi-package emerge statements that might or 
might not work correctly depending on what day of the week it is...

> them.  Just don't come asking us for help when you do things that we
> know will not work as expected.  We are not stupid.  We have been
> working with portage and Gentoo for a long time and know what is and is
> not possible quite well by now.

Did I say you were stupid?  And after this little experience, _I_ would be 
the stupid one for asking for help, as long as this is the response I get.