Mailing List Archive

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

pat wrote:
| Hi All,
|
| I have question, if the USE variable impacts on stage1 to stage3.
|
| Thanks to all.
|
| Pat

USE flags impact *all* applications (that use USE flags, that is). Which stage
you install from is irrelevant.

HTH
- --
And anyone can be tooted?

-- Homer Simpson, on tutoring
The Way We Was

Aaron Walker - Gentoo Developer [ Gentoo/BSD / forensics herd ]
ka0ttic@gentoo.org http://dev.gentoo.org/~ka0ttic/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBYoqzC3poscuANHARAnfWAKDxRBBks1NR7aOdFoAb4g4fm1r/4wCcCmaK
f8SK3Zr3XN1/B2ZWSqT2vIE=
=YymV
-----END PGP SIGNATURE-----

--
gentoo-user@gentoo.org mailing list

Thank you. So I should go through all USE possibilities carefully ;-)

Pat

On Tue, 05 Oct 2004 07:51:15 -0400, Aaron Walker wrote
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> pat wrote:
> | Hi All,
> |
> | I have question, if the USE variable impacts on stage1 to stage3.
> |
> | Thanks to all.
> |
> | Pat
>
> USE flags impact *all* applications (that use USE flags, that is).
> Which stage you install from is irrelevant.
>
> HTH
> - --
> And anyone can be tooted?
>
> -- Homer Simpson, on tutoring
> The Way We Was
>
> Aaron Walker - Gentoo Developer [ Gentoo/BSD / forensics herd ]
> ka0ttic@gentoo.org http://dev.gentoo.org/~ka0ttic/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBYoqzC3poscuANHARAnfWAKDxRBBks1NR7aOdFoAb4g4fm1r/4wCcCmaK
> f8SK3Zr3XN1/B2ZWSqT2vIE=
> =YymV
> -----END PGP SIGNATURE-----
>
> --
> gentoo-user@gentoo.org mailing list


--
gentoo-user@gentoo.org mailing list

On Tue, 5 Oct 2004 14:02:10 +0200 "pat" <pat@xvalheru.org> wrote:
| Thank you. So I should go through all USE possibilities carefully ;-)

Yup, probably best. The defaults are reasonably sane, though. Note that
you can't safely change USE flags after bootstrapping (except where you
can or where you get lucky).

--
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Tue, 5 Oct 2004, Ciaran McCreesh wrote:

> Yup, probably best. The defaults are reasonably sane, though. Note that
> you can't safely change USE flags after bootstrapping (except where you
> can or where you get lucky).

Urk. Really? Did I just miss the place where this was explained? Seems
like I've seen much advice that involved just this.

Dustin


--
gentoo-user@gentoo.org mailing list

begin quote
On Thu, 7 Oct 2004 20:09:51 -0700 (PDT)
Dustin <laurence@alice.caltech.edu> wrote:

> > Yup, probably best. The defaults are reasonably sane, though. Note
> > that you can't safely change USE flags after bootstrapping (except
> > where you can or where you get lucky).
>
> Urk. Really? Did I just miss the place where this was explained?
> Seems like I've seen much advice that involved just this.

He's mostly talking hot air. A few, undisclosed and unknown packages
have a unlogical behaviour with regards to how USE flags are handled,
most of this is that if you once had a dependency enabled, installed it,
then some packages may ignore the USE="-something" flag.

Theese are bugs and should be treated as such.


The other case where things may break is in second-line dependencies.


package:
foo== library, enabled with USE="+foo"
bar == library (uses foo if +foo is set)
baz == application that uses bar.

USE="+foo" emerge bar;
this installs foo and bar.

emerge baz;
this installs baz, that links to bar, and inherits some symbols and
functions from foo.

set USE="-foo"
emerge -C foo
emerge bar ; (since we just broke bar by removing foo from below it)

at this point, baz may break due to having things torn away from beneath
it. suggested is to use "revdep-rebuild" in cases like this, but,
this is only the case when applications and libraries are badly designed
and expose inherited symbols downwards. Could happen, but really
shouldn't.
(not much -we- can do about it other than bug upstream people though)


//Spider

--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

On Fri, 8 Oct 2004 10:22:00 +0200 Spider <spider@gentoo.org> wrote:
| begin quote
| On Thu, 7 Oct 2004 20:09:51 -0700 (PDT)
| Dustin <laurence@alice.caltech.edu> wrote:
|
| > > Yup, probably best. The defaults are reasonably sane, though. Note
| > > that you can't safely change USE flags after bootstrapping (except
| > > where you can or where you get lucky).
| >
| > Urk. Really? Did I just miss the place where this was explained?
| > Seems like I've seen much advice that involved just this.
|
| He's mostly talking hot air.

No, I'm really not. See, for example, the acl bug that was making
certain systems break because of a change in USE flags between stages
and the live system.

| The other case where things may break is in second-line dependencies.
| at this point, baz may break due to having things torn away from
| beneath it. suggested is to use "revdep-rebuild" in cases like this,
| but,
| this is only the case when applications and libraries are badly
| designed and expose inherited symbols downwards. Could happen, but
| really shouldn't.

revdep-rebuild will not catch all of these. The correct solution would
be to use the DEPEND="foo/bar[baz]" syntax, but since Nick doesn't care
about this it probably won't ever get implemented correctly. It's not
necessarily a library design problem either, there're totally sane and
legitimate places where this can crop up.

Really, if you think it's not an issue, try tinkering with pam, acl or
multilib sometime. It's a great way to totally screw up a system, and
part of the reason you can't mix binaries from systems with different
make.conf entries.

--
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

begin quote
On Fri, 8 Oct 2004 13:28:50 +0100
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

>
> No, I'm really not. See, for example, the acl bug that was making
> certain systems break because of a change in USE flags between stages
> and the live system.

stages-> live system was an issue of apps with expected symbols
inherited and not provided, because packages that were there on build
time weren't there on runtime. Bug yes.



>
> | The other case where things may break is in second-line
> | dependencies.
> | at this point, baz may break due to having things torn away from
> | beneath it. suggested is to use "revdep-rebuild" in cases like
> | this, but, this is only the case when applications and libraries are
> | badly designed and expose inherited symbols downwards. Could
> | happen, but really shouldn't.


> revdep-rebuild will not catch all of these.

it will catch packages that have exported inheritance and linking,
Which are the expectable kinds. The uncaught ones with missing symbols
due to SeriouslyBroken packages subexporting private interfaces are
other kinds of bugs.

> The correct solution would
> be to use the DEPEND="foo/bar[baz]" syntax, but since Nick doesn't
> care about this it probably won't ever get implemented correctly. It's
> not necessarily a library design problem either, there're totally sane
> and legitimate places where this can crop up.

Regarding this one, no, it wouldn't solve it for 100%, since it only
states the full dependency, although it could be used to force rebuilds
nicely, it doesn't fix the breakage I talked about earlier.

Actually, if "bar" in my case exposes symbols inherited from foo to the
subpackages, without ever giving them as hints for linking, its a bug in
either the packages using bar, or in bar.

(discussion about private and public symbols/functions can now ensure.
which part is broken ? ;)


> Really, if you think it's not an issue, try tinkering with pam, acl or
> multilib sometime. It's a great way to totally screw up a system, and
> part of the reason you can't mix binaries from systems with different
> make.conf entries.


I haven't been tinkering with multilib, however acl had that typical one
"oh its present, lets use it no matter what the USE flag" issue that
many packages exhibit. Thats the real danger in most cases.

pam is fairly hard-ingrained in my system, and I'm not going to be
tearing that out, since I'd loose part of my ~ for one. *cough*

Multilib I sort of understand as well, alsa and tcpd are other cases
where things may break (note though, so far I don't know of -any- case
with alsa/tcpd of subinheriting private symbols)


gtk+-1.2 has some of those, but noone wants to touch that source, so
packages that use gtk+-1.2 are silently broken now, and forever.
( ldd -r for examples )




//Spider

--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

On Fri, 8 Oct 2004 15:07:39 +0200 Spider <spider@gentoo.org> wrote:
| > No, I'm really not. See, for example, the acl bug that was making
| > certain systems break because of a change in USE flags between
| > stages and the live system.
|
| stages-> live system was an issue of apps with expected symbols
| inherited and not provided, because packages that were there on build
| time weren't there on runtime. Bug yes.

They were there at build time and not runtime because the acl USE flag
was changed.

| > revdep-rebuild will not catch all of these.
|
| it will catch packages that have exported inheritance and linking,
| Which are the expectable kinds. The uncaught ones with missing
| symbols due to SeriouslyBroken packages subexporting private
| interfaces are other kinds of bugs.

Not every package in the tree is written in c/c++... revdep-rebuild is
completely useless as soon as you hit the interpreted languages.

| > Really, if you think it's not an issue, try tinkering with pam, acl
| > or multilib sometime. It's a great way to totally screw up a system,
| > and part of the reason you can't mix binaries from systems with
| > different make.conf entries.
|
| I haven't been tinkering with multilib, however acl had that typical
| one"oh its present, lets use it no matter what the USE flag" issue
| that many packages exhibit. Thats the real danger in most cases.

No, the big problem was due to stages being shipped with the acl USE
flag turned on and users running systems with the acl flag turned off.

--
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

begin quote
On Fri, 8 Oct 2004 14:27:53 +0100
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> On Fri, 8 Oct 2004 15:07:39 +0200 Spider <spider@gentoo.org> wrote:
> | > No, I'm really not. See, for example, the acl bug that was making
> | > certain systems break because of a change in USE flags between
> | > stages and the live system.
> |
> | stages-> live system was an issue of apps with expected symbols
> | inherited and not provided, because packages that were there on
> | build
> | time weren't there on runtime. Bug yes.
>
> They were there at build time and not runtime because the acl USE flag
> was changed.


Actually, Thats about the same as :
echo USE="acl"
emerge -e system
USE="-acl"
emerge -C acl

Which is bound to break things, we already know this. The only solution
would be to at -C time parse through the ebuilds, check their built-with
USE flags and make sure they match the system they reside in.

This is done with .tbz2's when installed, and ought to be there when
doing a "safe" remove of a package.



This isn't the case of USE flags changing though, you can still change
the USE flag and -not- remove a package. Its the case that removing
packages in Gentoo is currently not implemented properly.



>
> Not every package in the tree is written in c/c++... revdep-rebuild is
> completely useless as soon as you hit the interpreted languages.

Yep, however, see above argument about where the brokenness is. I never
refuted that things break if we just tear dependencies out beneath a
package. I did say that packages that expose inherited, private symbols
down the line to packages that don't explicitly link to the one library
where the symbols originate from are broken.



>
> No, the big problem was due to stages being shipped with the acl USE
> flag turned on and users running systems with the acl flag turned off.

hmm. So you mean this scenario:
stage 1 install
USE="acl"
emerge system
USE="-acl"
-never removing the "acl" package -
emerge <stuff>

Will cause inherited symbols to collide or break?


Thats neat, although yet another proof that the acl implementation is
quite hackish... *sighs*


//Spider

--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

On 8 Oct 2004, at 06:27, Ciaran McCreesh wrote:
> | > revdep-rebuild will not catch all of these.
> |
> | it will catch packages that have exported inheritance and linking,
> | Which are the expectable kinds. The uncaught ones with missing
> | symbols due to SeriouslyBroken packages subexporting private
> | interfaces are other kinds of bugs.
>
> Not every package in the tree is written in c/c++... revdep-rebuild is
> completely useless as soon as you hit the interpreted languages.

Not quite true. Interpreted languages will generally use modules built
in C (as Python does) which can get rebuilt just fine.

On Fri, 8 Oct 2004 16:39:03 -0700 Andrew Farmer <andfarm@teknovis.com>
wrote:
| On 8 Oct 2004, at 06:27, Ciaran McCreesh wrote:
| > | > revdep-rebuild will not catch all of these.
| > |
| > | it will catch packages that have exported inheritance and linking,
| > | Which are the expectable kinds. The uncaught ones with missing
| > | symbols due to SeriouslyBroken packages subexporting private
| > | interfaces are other kinds of bugs.
| >
| > Not every package in the tree is written in c/c++... revdep-rebuild
| > is completely useless as soon as you hit the interpreted languages.
|
| Not quite true. Interpreted languages will generally use modules built
| in C (as Python does) which can get rebuilt just fine.

Well, they could... Most of the clever languages do it a different, more
flexible way however.

--
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On 9 Oct 2004, at 10:32, Ciaran McCreesh wrote:
> On Fri, 8 Oct 2004 16:39:03 -0700 Andrew Farmer <andfarm@teknovis.com>
> wrote:
> | On 8 Oct 2004, at 06:27, Ciaran McCreesh wrote:
> | > | > revdep-rebuild will not catch all of these.
> | > |
> | > | it will catch packages that have exported inheritance and
> linking,
> | > | Which are the expectable kinds. The uncaught ones with missing
> | > | symbols due to SeriouslyBroken packages subexporting private
> | > | interfaces are other kinds of bugs.
> | >
> | > Not every package in the tree is written in c/c++... revdep-rebuild
> | > is completely useless as soon as you hit the interpreted languages.
> |
> | Not quite true. Interpreted languages will generally use modules
> built
> | in C (as Python does) which can get rebuilt just fine.
>
> Well, they could... Most of the clever languages do it a different,
> more
> flexible way however.

And what would that be?