[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Michael Weber]

Hi folks,

this commit changes the set of USE flags on the just stabled gcc-4.6,
running a huge number into an rebuild of an freshly updated package.
(emerge --newuse recaclulates from "go disabled" to "go missing")

Wouldn't it be possible to
a) refrain from this change (really, who has USE=go turned on?)
b) handle this with package.use.mask,
c) figure it out before stabilization

I see the point in nobody beeing perfect, but these recurring
effect-less rebuilds of widespread base packages set me up.

Imho, editing /var/db/pkg/sys-devel/gcc-4.6.3/USE is not a recipe to be
carried out to the user. But can we do stuff like this in profile
updates? Without hurting system with USE=go activated, which need
actually need the recompile.

my 2 cents

   Michael


-------- Original Message --------
Subject: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog
toolchain.eclass
Date: Tue, 15 Jan 2013 02:30:53 +0000 (UTC)
From: Ryan Hill (dirtyepic) <dirtyepic@gentoo.org>
Reply-To: gentoo-dev@lists.gentoo.org, dirtyepic@gentoo.org
To: gentoo-commits@lists.gentoo.org

dirtyepic    13/01/15 02:30:53

  Modified:             ChangeLog toolchain.eclass
  Log:
  Drop go support for 4.6 - broken by newer glibc versions and upstream
recommends it not be used.

Revision  Changes    Path
1.615                eclass/ChangeLog

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.614&r2=1.615

Index: ChangeLog
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v
retrieving revision 1.614
retrieving revision 1.615
diff -u -r1.614 -r1.615
--- ChangeLog	13 Jan 2013 22:35:28 -0000	1.614
+++ ChangeLog	15 Jan 2013 02:30:53 -0000	1.615
@@ -1,6 +1,10 @@
 # ChangeLog for eclass directory
 # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.614 2013/01/13
22:35:28 eva Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.615 2013/01/15
02:30:53 dirtyepic Exp $
+
+  15 Jan 2013; Ryan Hill <dirtyepic@gentoo.org> toolchain.eclass:
+  Drop go support for 4.6 - broken by newer glibc versions and upstream
+  recommends it not be used.

   13 Jan 2013; Gilles Dartiguelongue <eva@gentoo.org> gnome2.eclass:
   Allow ebuild override of eclass generated econf.



1.567                eclass/toolchain.eclass

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.566&r2=1.567

Index: toolchain.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v
retrieving revision 1.566
retrieving revision 1.567
diff -u -r1.566 -r1.567
--- toolchain.eclass	29 Dec 2012 06:45:06 -0000	1.566
+++ toolchain.eclass	15 Jan 2013 02:30:53 -0000	1.567
@@ -1,6 +1,6 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.566
2012/12/29 06:45:06 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.567
2013/01/15 02:30:53 dirtyepic Exp $
 #
 # Maintainer: Toolchain Ninjas <toolchain@gentoo.org>

@@ -115,7 +115,7 @@
 		tc_version_is_at_least "4.3" && IUSE+=" fixed-point"
 		tc_version_is_at_least "4.4" && IUSE+=" graphite"
 		[[ ${GCC_BRANCH_VER} == 4.5 ]] && IUSE+=" lto"
-		tc_version_is_at_least "4.6" && IUSE+=" go"
+		tc_version_is_at_least "4.7" && IUSE+=" go"
 	fi
 fi






-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 02:20 AM, Michael Weber wrote:
> Hi folks,
> 
> this commit changes the set of USE flags on the just stabled
> gcc-4.6, running a huge number into an rebuild of an freshly
> updated package. (emerge --newuse recaclulates from "go disabled"
> to "go missing")
> 
> Wouldn't it be possible to a) refrain from this change (really, who
> has USE=go turned on?) b) handle this with package.use.mask, c)
> figure it out before stabilization
> 
> I see the point in nobody beeing perfect, but these recurring 
> effect-less rebuilds of widespread base packages set me up.
> 
> Imho, editing /var/db/pkg/sys-devel/gcc-4.6.3/USE is not a recipe
> to be carried out to the user. But can we do stuff like this in
> profile updates? Without hurting system with USE=go activated,
> which need actually need the recompile.
> 
> my 2 cents
> 
> Michael
> 

"  emerge -uD --reinstall=changed-use @world  "

This skips rebuilds for packages that receive new use flags or have
use flags removed but were already disabled.  Unfortunately it's not
as convenient to type as -uDN , but it does keep your system updated
while skipping spurious/unnecessary rebuilds.

[tangent]
I wonder if it might be pertinent for future portage's to install an
alias command, "emerge-system-update" or similar, that would wrap the
standardly accepted emerge update command more or less everyone
already runs..  easier end-user experience as they don't need to
learn/remember all the little fiddly options, plus portage dev's can
control the default (probably we make it over-ridable via a make.conf
var or something) so that if things change with newer EAPIs or portage
features the default flags can be adjusted too...
[/tangent]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1XUwACgkQ2ugaI38ACPA0WQD/RPIat2/eR6x2qRblQsc5xyVs
IhOj7bQdrM5Uou/Zn1cBAKnsBMYRlw4ZVhqOT7/4XCOl824dFp543jAO+hJeuErm
=zVJr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Rich Freeman]

On Tue, Jan 15, 2013 at 8:44 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> I wonder if it might be pertinent for future portage's to install an
> alias command, "emerge-system-update" or similar, that would wrap the
> standardly accepted emerge update command more or less everyone
> already runs..  easier end-user experience as they don't need to
> learn/remember all the little fiddly options, plus portage dev's can
> control the default (probably we make it over-ridable via a make.conf
> var or something) so that if things change with newer EAPIs or portage
> features the default flags can be adjusted too...

I'm fairly confident that this was already discussed a while back, and
generally had positive feedback.

I'd make it easy-to-remember though - either a one-letter option, or
something short.

To avoid rehashing the same arguments over again a few things to note:
1.  The settings would be reasonably conservative - intended for
newbies and such and unlikely to break things.
2.  We would not re-use any existing parameter - no changes in behavior/etc.
3.  Users could still throw alphabet soup at portage if they already
know the one-true-way (TM).
4.  Script writers would be warned up-front that the behavior of this
feature would be subject to change without much notice.

Is there any reason that this can't just be done?  It would only be an
alias, so it shouldn't really require development per-se.

Some open questions:
1.  What is the correct use-flag behavior - -N, or --reinstall=changed-use?
2.  What is the correct --with-bdeps behavior?
3.  What is the correct --deep behavior?

Now let the bikeshedding commence...

Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Dirkjan Ochtman]

On Tue, Jan 15, 2013 at 3:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I'd make it easy-to-remember though - either a one-letter option, or
> something short.

+1. Maybe just -U?

> Some open questions:
> 1.  What is the correct use-flag behavior - -N, or --reinstall=changed-use?
> 2.  What is the correct --with-bdeps behavior?
> 3.  What is the correct --deep behavior?

Seems to me that emerge -U should equal emerge -D --reinstall=changed-use.

Cheers,

Dirkjan

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 09:16 AM, Dirkjan Ochtman wrote:
> On Tue, Jan 15, 2013 at 3:03 PM, Rich Freeman <rich0@gentoo.org>
> wrote:
>> I'd make it easy-to-remember though - either a one-letter option,
>> or something short.
> 
> +1. Maybe just -U?
> 
>> Some open questions: 1.  What is the correct use-flag behavior -
>> -N, or --reinstall=changed-use? 2.  What is the correct
>> --with-bdeps behavior? 3.  What is the correct --deep behavior?
> 
> Seems to me that emerge -U should equal emerge -D
> --reinstall=changed-use.
> 
> Cheers,
> 
> Dirkjan
> 

Bikeshedding, but I'm thinking that it would be better to provide a
whole separate command for this rather than a quicker convenience
option -- the command would, for instance, also include @world as the
target by default.  As for the options, i'd recommend adding --ask and
- --verbose

The advantage I see for it being an extra command is that it's a clear
one-purpose convenience command; while if we use the '-U' option
there'll be others that will probably add additional modifier options
and possibly also use it against targets other than @world; i'm not
sure if we'd want people to do that by default..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1Z18ACgkQ2ugaI38ACPCNLQEAvi05mWKPbFZ0gi7yhSKieSY/
KA+THvQYTFSKDxyUTCUBAINfve059rg6IcGdBWc+HcGlRtny0T3miIM5mLER26br
=E0zR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Dirkjan Ochtman]

On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> Bikeshedding, but I'm thinking that it would be better to provide a
> whole separate command for this rather than a quicker convenience
> option -- the command would, for instance, also include @world as the
> target by default.  As for the options, i'd recommend adding --ask and
> - --verbose
>
> The advantage I see for it being an extra command is that it's a clear
> one-purpose convenience command; while if we use the '-U' option
> there'll be others that will probably add additional modifier options
> and possibly also use it against targets other than @world; i'm not
> sure if we'd want people to do that by default..

Yeah, but this is another command to remember. Since the purpose is
quite similar to other emerge actions, I think it should just be
provided by emerge (and documented clearly up top in man emerge and
emerge -h).

I was rather wondering about the other direction: include --deep and
--reinstall=changed-use in an --update action. This would actually
make more sense to me; I think those options still make sense for
single-package or other-set emerges?

I don't mind adding --ask and --verbose, but I think they should be
orthogonal. Some of this I guess depends on it being a separate
command. I think the better solution is to just provide a clear path
to upgrades, i.e. an -u/--update action with better defaults (even if
the backwards compatibility might be a little crappy -- might deserve
a news item).

BTW, what happened with -u? I still use it because I'm used to it, but
it seems to have gone away (i.e. I can't find it in the current man
page).

Cheers,

Dirkjan

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 09:39 AM, Dirkjan Ochtman wrote:
> 
> BTW, what happened with -u? I still use it because I'm used to it,
> but it seems to have gone away (i.e. I can't find it in the current
> man page).

It's there:
"
     --update (-u)
              Updates packages to the best version available, ...
"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1bH0ACgkQ2ugaI38ACPBl0AD/UF5lj7K1R65TWOcaaCf1NG41
dTPmGfvb6VldF4Fe+jUA/0uuZj1q51lYaylBQEP8TOrg8dZVlTLUsN02Fyr8S0g8
=qLlJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 09:39 AM, Dirkjan Ochtman wrote:
> On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> Bikeshedding, but I'm thinking that it would be better to provide
>> a whole separate command for this rather than a quicker
>> convenience option -- the command would, for instance, also
>> include @world as the target by default.  As for the options, i'd
>> recommend adding --ask and - --verbose
>> 
>> The advantage I see for it being an extra command is that it's a
>> clear one-purpose convenience command; while if we use the '-U'
>> option there'll be others that will probably add additional
>> modifier options and possibly also use it against targets other
>> than @world; i'm not sure if we'd want people to do that by
>> default..
> 
> Yeah, but this is another command to remember. Since the purpose
> is quite similar to other emerge actions, I think it should just
> be provided by emerge (and documented clearly up top in man emerge
> and emerge -h).
> 
> I was rather wondering about the other direction: include --deep
> and --reinstall=changed-use in an --update action. This would
> actually make more sense to me; I think those options still make
> sense for single-package or other-set emerges?
> 
> I don't mind adding --ask and --verbose, but I think they should
> be orthogonal. Some of this I guess depends on it being a separate 
> command. I think the better solution is to just provide a clear
> path to upgrades, i.e. an -u/--update action with better defaults
> (even if the backwards compatibility might be a little crappy --
> might deserve a news item).
> 


I don't know about changing default -u behaviour...  I still use
'emerge -u [package]' for instance if I want to upgrade just one
package.  I'd rather not have to negate the --deep and
- --reinstall=changed-use  (well, the --deep, anyhow) when i do this.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1bVsACgkQ2ugaI38ACPDRsAD/abiZ2hMlUXfoGAbsxM8E2e+0
P364P8o+QjcP6pN/xccA/iq//d3FqpcvllLlxWg9yLto2YgR8z4T2imjEDWurdki
=orNG
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Rich Freeman]

On Tue, Jan 15, 2013 at 9:39 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> Bikeshedding, but I'm thinking that it would be better to provide a
>> whole separate command for this rather than a quicker convenience
>> option -- the command would, for instance, also include @world as the
>> target by default.  As for the options, i'd recommend adding --ask and
>> - --verbose

++ to including @world and --ask / --verbose.  We really want a simple
command that "does it all" with fairly conservative settings.

Anybody who runs debian knows that the only two commands you really
need to know are apt-get --update and apt-get --upgrade.  We really
need to keep things just that simple.  apt-get prompts if the install
pulls in extra dependencies, and is fairly verbose.

I don't really care if it is a separate command or built-into emerge.
One thing the command probably should do is echo the full command
expansion.  Then users know exactly what is going on under the hood,
and if they need to tweak the command they can just do a copy-paste or
define their own alias.

>>
>> The advantage I see for it being an extra command is that it's a clear
>> one-purpose convenience command;
>
> Yeah, but this is another command to remember.

I'm not sure I agree here - for the "typical" Gentoo user it might be
the only command to remember.

> I was rather wondering about the other direction: include --deep and
> --reinstall=changed-use in an --update action. This would actually
> make more sense to me; I think those options still make sense for
> single-package or other-set emerges?

I'm not keen on redefining existing options.  That is going to lead to
a bazillion complaints about broken scripts, and sometimes you really
do just want to do a partial resolution.

>
> I don't mind adding --ask and --verbose, but I think they should be
> orthogonal.

For the one-size-fits-all default command, I think they should be
defaults.  By all means have --quiet and --non-interactive or
whatever, but I think the default should be ask and verbose.  Keep in
mind this is the command that newbies will run.  It doesn't mean that
any existing options will be disabled.

The goal is that the Gentoo handbook will introduce new users to
maintaining their systems by giving them a single command that they
should run daily, or whatever.  It should nearly guarantee that users
will not run into valid bugs, and if for some reason the upgrade path
on some package requires deviation from this command it should be
considered as a news item.

The side goal is to get rid of unnecessary diversity.  I'm fine with
users doing things differently because they have different needs and
we should of course support this.  However, I think too often every
Gentoo box ends up being maintained completely differently just
because we're so wishy-washy with the defaults.  We shouldn't be
afraid of declaring a reasonable default, and then just letting
individuals change it.

Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Peter Stuge]

Rich Freeman wrote:
> Anybody who runs debian knows that the only two commands you really
> need to know are apt-get --update and apt-get --upgrade.  We really
> need to keep things just that simple.

We're halfway there;

emerge --sync

So how about adding:

emerge --upgrade

?


//Peter

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Dirkjan Ochtman]

On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge <peter@stuge.se> wrote:
> We're halfway there;
>
> emerge --sync
>
> So how about adding:
>
> emerge --upgrade
>
> ?

I was thinking the same thing!

Cheers,

Dirkjan

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Weber]

On 01/15/2013 09:51 PM, Dirkjan Ochtman wrote:
> On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge <peter@stuge.se> wrote:
>> emerge --sync
   layman -S
   eix-sync #layman...
   porticron # from porticron
   update-gentoo # cvs setup https://xmw.de/dotfiles/bin/update-gentoo

>> emerge --upgrade
with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
EMERGE_DEFAULT_OPTS lives).

But ++ on that
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

On 01/16/2013 11:36 AM, Michael Weber wrote:
> 
>>> emerge --upgrade
> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
> EMERGE_DEFAULT_OPTS lives).

+1 so I can stop adding --oneshot onto every upgrade.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

On 01/16/2013 11:47 AM, Michael Orlitzky wrote:
> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>
>>>> emerge --upgrade
>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where
>> EMERGE_DEFAULT_OPTS lives).
> 
> +1 so I can stop adding --oneshot onto every upgrade.

Oh, damn, this isn't suggesting what I thought. Allow me to suggest that
having both --update and --upgrade might be confusing, then =)


p.s. EMERGE_UPDATE_OPTS would still be nice.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/13 11:49 AM, Michael Orlitzky wrote:
> On 01/16/2013 11:47 AM, Michael Orlitzky wrote:
>> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>> 
>>>>> emerge --upgrade
>>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
>>> EMERGE_DEFAULT_OPTS lives).
>> 
>> +1 so I can stop adding --oneshot onto every upgrade.
> 
> Oh, damn, this isn't suggesting what I thought. Allow me to suggest
> that having both --update and --upgrade might be confusing, then
> =)
> 
> 
> p.s. EMERGE_UPDATE_OPTS would still be nice.
> 


- --upgrade wouldn't (couldn't, imo) replace --update.

"emerge --upgrade" would ideally meant to be run with no options
(except for maybe --keep-going and --jobs), and would consider @world
without specifying it.  We would, I think, need to define what happens
when other things are specified as options (ie throw them out and/or
error), which is why I have reservations of "emerge --upgrade" over a
separate say, "eupgrade" command; i don't think the usual pile-on
should occur.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD24joACgkQ2ugaI38ACPA4vwD8DqGsXOXKiKEzeQI98VytM9zg
4FX6fQ1ENwBeiZu17rkA/2IxItrBer06jy5bIWONCxjy+ysqj+BBTrY5oININVNE
=3chs
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

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

On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
> 
> --upgrade wouldn't (couldn't, imo) replace --update.
> 

Yes, sorry for the confusion. I use more than one package manager, and
when doing an "update" or "upgrade" I'm basically flipping a coin.

I just mistook "upgrade" for "update," there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ9uRUAAoJEBxJck0inpOiLSYQAIHekN2gLD8XRhd6kCulCWkk
p4RcBmuuHM8p06GC1VzSlGmOlhezIXnt3lnstsUG3tJvIDz443Q7EChqLfg5mLTX
x1zrPxgIoFaJ7go+EbbmiyP2UNd6Hx2sWIuc7ed+NE49UZ59ZmG38SjhYdEtkZ8e
D62BMfUqYmEbibIKXq93S6WawAuolFTYwLINbiebThHUT3dSid21LdEk2isI1+tS
QMqnwqPPobYoAECrWCLQawLkMU1SHHcokGriNDEQDb2pNgHr8SJu85CkgGk/PcAX
sFDB/X7IwKVzwsdB9/YGxyt896VhtgUs83szqNbhNxiTzt17FtyFhtVehIoS9nbg
GTMteIIU5vHNXDaksnSigegYtcRWv9vf+tJHTTHkj4O+Z0SLN5cSFSjMOveYKVVA
3MXAvz/2KD2vPqv9yJ1pXhdvaqTu93mx3Ps20a6AWyOyjn4m7FNEyyhM0LEVMijA
mEP5krIO6QFaI50Z3hDVxX/Djwf+uynHUVQERxrqaZVeRwVBmeQTQw4ZMjNmGsNv
Cm4xDabivluvRVdmBV9hpiiFWnJlwvgEFBurCSqgeOAr7NRa3P5z37YqISno5zKg
8EGmqdPv9xjcSLkD5q9GoI3V1l7uBwCq0NTsXOJaHXxmW7HG1CbprL1dehSQPiCB
Wle+0CtUdW2Dr0hUE5XR
=i6LB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/16/2013 06:33 PM, Michael Orlitzky wrote:
> Yes, sorry for the confusion. I use more than one package manager,
> and when doing an "update" or "upgrade" I'm basically flipping a
> coin.
hehe, as long as we don't --dist-upgrade ;-)
the g was intentional.

how does portage @preserved-libs work? maybe we could emerge
@update[s] and @glsa.

https://wiki.archlinux.org/index.php/Pacman_Rosetta

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlD3PyYACgkQknrdDGLu8JDKOAEAlSRRrurL7VWpeMMtB2sVZeH4
Ik+D3d5LL1Nahflz+PIBAIWVFvyuNmzgnvE+wOpU70AIacTbprFcFJFOe9JaVBVr
=gKRT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Rich Freeman]

On Wed, Jan 16, 2013 at 7:00 PM, Michael Weber <xmw@gentoo.org> wrote:
> how does portage @preserved-libs work? maybe we could emerge
> @update[s] and @glsa.

@glsa actually makes a lot of sense.  I'm not convinced we want
@updates as a shortcut for a bunch of settings though.  Sets are just
about picking which packages to operate on, and overloading them in
this way is going to just lead to confusion.  Sets should be nothing
more than lists of packages, and then the other emerge parameters can
be used to filter them.

I'd just stick with a simple parameter like --upgrade or an
alternative command name like emerge-update.

Oh, here's another crazy thought.  How about some directory in /etc
that sets rules for emerge-update (or whatever we call it)?  You might
have a bunch of low-numbered rules that set/append variables like
EMERGE_DEFAULT_OPTIONS, and then a bunch of higher-numbered rules that
actually run commands.  Then if you install eix or layman they could
stick a hook in there to trigger their own respective updates.  A
downside is that it makes the behavior of the command a bit less
predictable.  An upside is that the behavior of the command will only
change subject to config file protection (well, sort-of - additional
rule files don't typically trigger protection).

Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Peter Stuge]

Rich Freeman wrote:
> I'd just stick with a simple parameter like --upgrade

Yes please!

> or an alternative command name like emerge-update.

Please no!


> Oh, here's another crazy thought.  How about some directory in /etc
> that sets rules for emerge-update (or whatever we call it)?  You might
> have a bunch of low-numbered rules that set/append variables like
> EMERGE_DEFAULT_OPTIONS, and then a bunch of higher-numbered rules that
> actually run commands.  Then if you install eix or layman they could
> stick a hook in there to trigger their own respective updates.

I like it.


//Peter

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/13 10:24 PM, Rich Freeman wrote:
> On Wed, Jan 16, 2013 at 7:00 PM, Michael Weber <xmw@gentoo.org>
> wrote:
>> how does portage @preserved-libs work? maybe we could emerge 
>> @update[s] and @glsa.
> 
> @glsa actually makes a lot of sense.  I'm not convinced we want 
> @updates as a shortcut for a bunch of settings though.  Sets are
> just about picking which packages to operate on, and overloading
> them in this way is going to just lead to confusion.  Sets should
> be nothing more than lists of packages, and then the other emerge
> parameters can be used to filter them.
> 
> I'd just stick with a simple parameter like --upgrade or an 
> alternative command name like emerge-update.
> 
> Oh, here's another crazy thought.  How about some directory in
> /etc that sets rules for emerge-update (or whatever we call it)?
> You might have a bunch of low-numbered rules that set/append
> variables like EMERGE_DEFAULT_OPTIONS, and then a bunch of
> higher-numbered rules that actually run commands.  Then if you
> install eix or layman they could stick a hook in there to trigger
> their own respective updates.  A downside is that it makes the
> behavior of the command a bit less predictable.  An upside is that
> the behavior of the command will only change subject to config file
> protection (well, sort-of - additional rule files don't typically
> trigger protection).
> 
> Rich
> 

That is a very interesting idea -- especially considering the
implications of multiple stages, ie, "emerge-update" could be
configured to --sync, then -uDwhatever @world , then --depclean, then
revdep-rebuild, simply by having four entries in /etc/emerge-update.

Of course when looking at this kind of functionality we're probably
looking at something that would almost be better to leave as a
separate package (at least in the beginning) rather than putting it
drectly into portage; and that means it won't be universal yet...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4EZ4ACgkQ2ugaI38ACPCtTQD+MyI8PDPfgqm//8S3U3bFDiNr
DE7OZKbhb1oAOEFzP+oA/RY3rFxbAmEDm7S2YpnKWvaGRi/bIe8fNjFXYV03ugIz
=6MPD
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Zac Medico]

On 01/16/2013 04:00 PM, Michael Weber wrote:
> On 01/16/2013 06:33 PM, Michael Orlitzky wrote:
>> Yes, sorry for the confusion. I use more than one package manager,
>> and when doing an "update" or "upgrade" I'm basically flipping a
>> coin.
> hehe, as long as we don't --dist-upgrade ;-)
> the g was intentional.
> 
> how does portage @preserved-libs work?

@preserved-rebuild is a package set, which is intended to be obsoleted
by EAPI 5 slot-operator automatic rebuilds, as I've mentioned in this
blog post:

http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/

> maybe we could emerge @update[s]

The @ symbol is reserved for package sets, which expand to a set of
atoms that are used to select a specific set of packages. Package sets
are intended to be orthogonal emerge options.

> @glsa.

In portage-2.2 we have the @security package set, which generates atoms
from the intersection of the glsa database with your installed packages.
The @security code has not been kept in sync with glsa-check (from
gentoolkit), so it may contain bugs that have already been fixed in
glsa-check.
-- 
Thanks,
Zac

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/13 11:47 AM, Michael Orlitzky wrote:
> On 01/16/2013 11:36 AM, Michael Weber wrote:
>> 
>>>> emerge --upgrade
>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
>> EMERGE_DEFAULT_OPTS lives).
> 
> +1 so I can stop adding --oneshot onto every upgrade.
> 
> 

btw, why are you adding --oneshot when upgrading??  emerge -u doesn't
ever modify the world file...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD24mMACgkQ2ugaI38ACPBJnwEAhHm7oV8MNKpWnHnZ/Vqvxy6C
OTXNJzErpfJvuLXIAdYA/jdOQDT441rgC8Y11E32GKBJp2kTiK25vF3hEC7s95v2
=ZAyY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

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

On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
> On 16/01/13 11:47 AM, Michael Orlitzky wrote:
>> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>> 
>>>>> emerge --upgrade
>>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
>>> EMERGE_DEFAULT_OPTS lives).
> 
>> +1 so I can stop adding --oneshot onto every upgrade.
> 
> 
> 
> btw, why are you adding --oneshot when upgrading??  emerge -u
> doesn't ever modify the world file...
> 

I strongly believe that it shouldn't; nevertheless, it does.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ9uQiAAoJEBxJck0inpOiIgMP/A7prLxpcPh3ZNF0ZWmcbj35
igZi6qXJJHCKYRUzXNYbUfVWFnMc/l9ryjVn9fosvpggyQBBq99zneAh+IARcDPI
XpXGe+wzg3NHvvTa9Xe93Wg2VQ5a/efGaH9mEeQ0YPQd0b/NNodfxn4nSKa48Ulb
7aWumzW4I4Xmu5E77L7q1alfatKf/0w1YGMLZpvnITAdBRNDcDQZtXpzXvRl6zwr
eUwnbjqNJanmaKtvjPXU+BCW+sjtO2JjVX4L/o/qwMHMHJtVk44mNY262BLkg99N
dJ1evNg/1sU+CAni/sPOgyjttR+UGgRq7x7nWXBPmQRS2X1Z5Beira/GqZ/8mKFC
pUOQ3+AFcbK8h6BupwFazybQGbFUODs2eh/J9TfSnw1j4sicoGHAwz8Z2EPYtRIc
Pa3NCqvaOyPSP5W4SCbYN5OOGEFxmHKPH3oK3ddtJ+6BOci58dcbSm3+FMGbuCpu
txKQxfPtNRvZ4CdKkvocz83nMLpFYqr7uSQFSYARjXH0shnS40ajM6E5LZy+LELa
94rPLgAct7E4KZOjKm+o6wvStMi0S+aP3+1DI1dciOF0xlTSYZic6ggt39G+pNqU
dIgXaKRrd2e4+aeP2IP8iiTddfnUkOXOlxa047dNfOS7B8d6d/aJ6CZKYRWKf6gS
ZYIkpFr3OJDYPGp7oxhx
=BsDW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Zac Medico]

On 01/16/2013 09:32 AM, Michael Orlitzky wrote:
> On 01/16/2013 12:24 PM, Ian Stakenvicius wrote:
>> On 16/01/13 11:47 AM, Michael Orlitzky wrote:
>>> On 01/16/2013 11:36 AM, Michael Weber wrote:
>>>>
>>>>>> emerge --upgrade
>>>> with a predefined EMERGE_UPGRADE_OPTS in make.conf (where 
>>>> EMERGE_DEFAULT_OPTS lives).
> 
>>> +1 so I can stop adding --oneshot onto every upgrade.
> 
> 
> 
>> btw, why are you adding --oneshot when upgrading??  emerge -u
>> doesn't ever modify the world file...
> 
> 
> I strongly believe that it shouldn't; nevertheless, it does.

You can avoid this by adding --select=n to EMERGE_DEFAULT_OPTS. Then, if
you want to add something to world, use --select (or -w in latest
portage which isn't marked stable yet).
-- 
Thanks,
Zac

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

On 01/17/2013 09:52 AM, Zac Medico wrote:
>>
>> I strongly believe that it shouldn't; nevertheless, it does.
> 
> You can avoid this by adding --select=n to EMERGE_DEFAULT_OPTS. Then, if
> you want to add something to world, use --select (or -w in latest
> portage which isn't marked stable yet).

This works by moving the badness from `emerge -u` to `emerge`. In either
case, to keep your world file accurate, you have to remember to type an
additional useless parameter every time you run the command. When you're
running depclean, you have to cross your fingers and hope nobody forgot
the magic --dont-break-world parameter.

I've  "solved" this by installing every single package as a dependency
of something in our company repo. So we emerge
dev-util/mike_wants_to_be_able_to_run_strace_on_apache (depending on
strace) instead of dev-util/strace. This makes it obvious what can be
removed; we don't have normal packages listed in the world file, so if
you see one, it was a mistake.

But it's not a very good solution,

  * It's a lot of work

  * I have to be the gatekeeper for every package install on every
    server

  * It's stupid

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 11:31 AM, Michael Orlitzky wrote:
> On 01/17/2013 09:52 AM, Zac Medico wrote:
>>> 
>>> I strongly believe that it shouldn't; nevertheless, it does.
>> 
>> You can avoid this by adding --select=n to EMERGE_DEFAULT_OPTS. 
>> Then, if you want to add something to world, use --select (or -w 
>> in latest portage which isn't marked stable yet).
> 
> This works by moving the badness from `emerge -u` to `emerge`. In 
> either case, to keep your world file accurate, you have to
> remember to type an additional useless parameter every time you run
> the command. When you're running depclean, you have to cross your 
> fingers and hope nobody forgot the magic --dont-break-world 
> parameter.
> 
> I've  "solved" this by installing every single package as a 
> dependency of something in our company repo. So we emerge 
> dev-util/mike_wants_to_be_able_to_run_strace_on_apache (depending 
> on strace) instead of dev-util/strace. This makes it obvious what 
> can be removed; we don't have normal packages listed in the world 
> file, so if you see one, it was a mistake.
> 
> But it's not a very good solution,
> 
> * It's a lot of work
> 
> * I have to be the gatekeeper for every package install on every 
> server
> 
> * It's stupid
> 
> 

... so what's the problem here, exactly?

(a) 'emerge -u [pkg]' adds extra bits to @world when you don't want it
to, or
(b) you have users running 'emerge [pkg]' and you don't want THAT to
end up in world either, or
(c) you ONLY want 'emerge [pkg]' to end up adjusting world, AND only
doing so for certain packages?

It seems from your description you're trying to prevent all three
issues..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4MNIACgkQ2ugaI38ACPCPDwEAuiRjf33Y63iIDH0M5ruwo43u
TdnYhkWD8Yz5Xq/WM7gA/jjea2n3dML1p5waCJqPp5F5vlLlLizXO7Js81/xjbVb
=Pg74
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

[Michael Orlitzky]

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

On 01/17/2013 12:11 PM, Ian Stakenvicius wrote:
> 
> ... so what's the problem here, exactly?
> 

I don't want @world to get screwed up, either by having unnecessary
packages, or by missing ones we need.


> (a) 'emerge -u [pkg]' adds extra bits to @world when you don't want
> it to, or

This is all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQ+DX0AAoJEBxJck0inpOi59AP/0D5PC81E6BIVauVx5bciaji
eL1iSBv5tRbZCT7YzQTehDdunOI8joZGmEHXyHgMBzGwUSuSHYw1XWUSfPIRYof5
MJKJacMwQozU6lpmh4txLk8VxifDvquPHl0Yf/5ZPELDm6CWWw30Czk1itFPNNH2
KQZhQAMvWEluAYjQzJX+ATjdVKcFPZCRivAt7EwuVqZNGqWkTr5rw+FKr5HZXmbY
8rO/zLiwOBwuZyKjCg4Q+pA4AcPJIC88GVzAh+c+6L6eI6q9zfP4MA7hPDDVzXS8
+ulnE7naVVlD6x0slec5ALVEvgDO8xVr86sZFB6ixoxoKgmej1hTI/N9wtUYoLCk
rwZhNpX0N0fKAPm0Fuo+QlcIqUvZxUpgaoXrWV3jgsYcZuLQ9HcQFrWT8gU0gQci
FbmdQuKGQfNvPBl8cTvirt1ff55ggz4YeehZg2a7Gd1gn72tVdHv2n0yUDrBXAJk
AN83WDHQJuIN8F6Ik16P1dlAafTk26YFBKm635E4ez1fsZKOPe6LAt4yu+O0Nt/L
+pCstX2Bm1O8LvVpxoFRHNHuPaddyG+JTORNyFLZPSsa3+MspX8OjMGXKDJUknXv
y1v5G2t7HqVm2Fip5c4doVbXi4Oar+SSpu3BfYn1C1HiKHKaqlnJD//q6pPDW4BR
R69ClYDffLoMcT8aZNTC
=nMMV
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Stable sys-devel/gcc USE flag changes

[Duncan]

Michael Orlitzky posted on Thu, 17 Jan 2013 11:31:53 -0500 as excerpted:

> In either case, to keep your world file accurate, you have to remember
> to type an additional useless parameter every time you run the command.
> When you're running depclean, you have to cross your fingers and hope
> nobody forgot the magic --dont-break-world parameter.
> 
> I've  "solved" this by installing every single package as a dependency
> of something in our company repo. So we emerge
> dev-util/mike_wants_to_be_able_to_run_strace_on_apache (depending on
> strace) instead of dev-util/strace. This makes it obvious what can be
> removed; we don't have normal packages listed in the world file, so if
> you see one, it was a mistake.

Different (and IMO nicer, but it requires portage sets support) solution 
here, same problem.

Two part solution:

1) For years, I've had a set of aliases to emerge, most of which add -1, 
so I don't have to worry about world-file pollution.  The aliases break 
down into two sets, ea* and ep*, emerge --ask and emerge --pretend.  

Examples:

eaw	emerge --ask @world (--update --deep --newuse are there too, and 
--jobs, etc, --with-bdeps=y is in my emerge defaults)

epw	same thing basically, but --pretend instead of --ask.

eptw	emerge --pretend --tree @world

ea	emerge -av1 $*

epl	emerge -pvlO $* (see the changelog for an upgrade before I do it)

Significant to this discussion:

ea2	emerge -av --select $* (the 2 being shorthand for NOT oneshot)

(I have tab-completion stubs built on the normal emerge completions, too, 
so get full tab-completion on my short forms. =:^)


I don't even /use/ the long forms any longer, except for copying to bugs, 
etc, only my short forms.  So no weird stuff in @world, as I have -1 on 
my short forms by default, and specifically use the e*2 forms when I WANT 
it in world.  As I said, I've been doing this for years now.

2) Portage sets support made things even better.  They first appeared 
shortly before I setup my netbook, and in the process of going thru my 
existing world file to figure out what I wanted on the netbook, I simply 
split the world file into a bunch of categorized sets, beginning with the 
kde sets, which I manage in parallel to the ones found in the kde overlay 
(but with some package entries commented out), but extended to dev, 
net.admin, net.user, etc.

Now my world-file is normally empty, with all packages that would 
normally be in world listed in a set instead, with the sets in turn 
listed in the world_sets file.

So there's only two conditions under which a package would be listed in 
the world file instead of in a set to be found in world_sets:

2a) I sometimes use the world file as a "package purgatory", for packages 
I'm testing so I don't want them removed by depclean, but I've not yet 
decided to keep, so I don't want them in my normal sets, either.  The 
world file is thus a very convenient middle ground. =:^)

2b) I somehow made a mistake, and something ended up in world that 
shouldn't have.  (Due to my longstanding alias usage, this case has so 
far been entirely theoretical; I've not made that mistake since the 
introduction of sets... yet.  But I'm glad the protection's there, in 
case I do. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Tue, 15 Jan 2013 08:20:53 +0100
Michael Weber <xmw@gentoo.org> wrote:

> Hi folks,
> 
> this commit changes the set of USE flags on the just stabled gcc-4.6,
> running a huge number into an rebuild of an freshly updated package.
> (emerge --newuse recaclulates from "go disabled" to "go missing")

Eh?  I thought it stopped doing that.  My bad.

> Wouldn't it be possible to
> a) refrain from this change (really, who has USE=go turned on?)

apparently none of the arch testers. :p

> b) handle this with package.use.mask,
> c) figure it out before stabilization

d) just rebuild the package and go on with your life


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Michael Weber]

Hi,

I'd like to drop one strong suggestion about configuration management
that might be beneficial here: use version control software!

Some machines (esp. those with shared administration) have /etc/portage
under git [1] with
 - /var/lib/portage/world symlinked to /etc/portage/world
 - PORTDIR_OVERLAY=/etc/portage/local-overlay

Basically, we have 4 roots fiddling with 4 machines and different
behaviours.

Some forget --oneshot (-1) on broken-libs rebuilds,
some forget to mark packages in world file after successful tests.
Some forget the second > on `echo foo-bar/blub >
/etc/portage/package.keywords/global`
Some forget to commit+push their changes.

All these "problems" esp. the mentioned world file pollution is
documented quite well in the git log, or doesn't get committed at all.

I check `cd /etc/portage ; git stash show ; git diff` on a regular basis
o keep it all together.

The update is almost unattended with [2].

General benefits:
 - You can recover from moronic file handling
 - The changes to the machines get documented (and announced by mail)
 - Config changes and updates can be made w/o all machines being up.
 - It feels like an normal machine, no need to run any deployment tool
to just test-install a package.

Down drafts:
 - Doesn't handle layman repo list
 - Git merge is bad on two changes adding a new last line
 - autoupdate.sh doesn't handle error exit codes.

So, __USE__ an version control, even when you're just running
`cd /etc/portage ; git commit -a -m "randoom updates"` from time to time.

Bye

[1] http://git.fs.lmu.de/gaf-etc-portage.git/

[2] http://git.fs.lmu.de/gaf-etc-portage.git/blob/HEAD:/bin/autoupdate.sh

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Benedikt Böhm]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber <xmw@gentoo.org> wrote:

> Hi,
>
> I'd like to drop one strong suggestion about configuration management
> that might be beneficial here: use version control software!
>
> Some machines (esp. those with shared administration) have /etc/portage
> under git [1] with
>

or even /etc/.git ... it saved my life on numerous occasions

The update is almost unattended with [2].
>

for reference, here is my updateworld script, which also handles python,
ruby, perl, revdep-rebuild and all that crap:
https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld

- Bene

[-- Attachment #2: Type: text/html, Size: 1423 bytes --]

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Michael Weber]

On 01/18/2013 08:36 AM, Benedikt Böhm wrote:
> On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber <xmw@gentoo.org
> <mailto:xmw@gentoo.org>> wrote:
>     I'd like to drop one strong suggestion about configuration management
>     that might be beneficial here: use version control software!
> or even /etc/.git ... it saved my life on numerous occasions

Sure, bit thats's the point were diversity (hostnames, ssh_host_keys)
kicks in (which has been eliminated in mentioned example) and
the repo carries confidential information.
(Well, if somebody places an compromised update in the
 local-overlay, i'd blindly install anything)

I even have / inside git for testing, with excludes on /opt/ /usr
/{s,}/bin /etc/ssl and so on.

It works and is handy to easily add apache config, web-app-config
installed roundcube, layman overlay list, but the maintenance of the
.gitignore raises and hardlink solutions like dirvish make more sense
for being complete backups (LD_LIBRRY_PATH=/backup/.../tree/usr/lib).

> for reference, here is my updateworld script, which also handles python,
> ruby, perl, revdep-rebuild and all that
> crap: https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld
cool.

So basically everyone uses personal `apt-get update` (cvs co, porticron,
emerge+layman, eix-sync) strategies and even more
funny little scripts for `apt-get upgrade` (-avuND world, aliases,
scripts).

I wonder if anybody uses unattended [backup+]emerge as cron job.
I'm really temped to do so, but with users relying on these machines I'm
always chicken-out.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Benedikt Böhm]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Fri, Jan 18, 2013 at 9:13 AM, Michael Weber <xmw@gentoo.org> wrote:

> I wonder if anybody uses unattended [backup+]emerge as cron job.
> I'm really temped to do so, but with users relying on these machines I'm
> always chicken-out.
>

i've refrained from doing unattended upgrades for a long time, but i'm
quite confident in updateworld these days and i usually test it on 2-3
machines and then let the other 50+ machines do it unattended and it has
been working fine so far ...

but - and that's quite important i guess - i only use my own clone of the
portage tree which i sync from time to time and i also keep different
versions stable, etc.

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Michael Weber]

On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
> i've refrained from doing unattended upgrades for a long time, but i'm
> quite confident in updateworld these days and i usually test it on 2-3
> machines and then let the other 50+ machines do it unattended and it has
> been working fine so far ...
good strategy.

> but - and that's quite important i guess - i only use my own clone of
> the portage tree which i sync from time to time and i also keep
> different versions stable, etc.
HEAVY USER! But you have full control.
Do you have any sophisticated mechanism to detect tree breakage (i.e. us
f*** up), like Samuli replying -commit to -dev or irc activity?

Or do you simply delay commit? (re-schedule on weekends/nights)

Delaying stabilization seems legit, but on Gentoo-stable ?!

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Benedikt Böhm]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber <xmw@gentoo.org> wrote:

> On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
> > but - and that's quite important i guess - i only use my own clone of
> > the portage tree which i sync from time to time and i also keep
> > different versions stable, etc.
> HEAVY USER! But you have full control.
> Do you have any sophisticated mechanism to detect tree breakage (i.e. us
> f*** up), like Samuli replying -commit to -dev or irc activity?
>
> Or do you simply delay commit? (re-schedule on weekends/nights)
>

i manually sync with the gentoo-x86 repo from time to time (except security
issues, which i sync as soon as they are fixed)

i have no automated way to detect any tree breakage, but when i sync the
complete tree i do extensive manual testing on a handfull of machines
(either staging machines, or ones that are not really important)

but the main reason i even have a clone is to sync updates in batches. it's
really a hassle to keep servers in sync when changes to gentoo-x86 happen
any other minute. i also need to adapt my chef cookbooks for some updates,
so i do it all in one batch (sync, test, adapt, test, deploy)


> Delaying stabilization seems legit, but on Gentoo-stable ?!
>

it's not really about delaying stabilization ... there is quite a big list
of packages in my repo where i always stabilize the latest version(s) even
if gentoo-x86 is unstable. e.g. i've stabled openrc a looong time before
gentoo-x86 had it stable, etc.

it's also a lot easier to add new packages because i don't have to support
everything and the kitchen sink ... my repo just supports amd64 and it also
has quite a few binary ebuilds which would not be a good fit for gentoo-x86

if you're interested, it's all on github:
https://github.com/zentoo/zentoo(all the sync tools are in the script
directory and were initially copied
from the prefix guys, but have been heavily modified since ...)

Cheers,
Bene

[-- Attachment #2: Type: text/html, Size: 2906 bytes --]

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Benedikt Böhm]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On Fri, Jan 18, 2013 at 2:13 PM, Benedikt Böhm <hollow@gentoo.org> wrote:

> On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber <xmw@gentoo.org> wrote:
>
>> On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
>> > but - and that's quite important i guess - i only use my own clone of
>> > the portage tree which i sync from time to time and i also keep
>> > different versions stable, etc.
>> HEAVY USER! But you have full control.
>> Do you have any sophisticated mechanism to detect tree breakage (i.e. us
>> f*** up), like Samuli replying -commit to -dev or irc activity?
>>
>> Or do you simply delay commit? (re-schedule on weekends/nights)
>>
>
> i manually sync with the gentoo-x86 repo from time to time (except
> security issues, which i sync as soon as they are fixed)
>
> i have no automated way to detect any tree breakage, but when i sync the
> complete tree i do extensive manual testing on a handfull of machines
> (either staging machines, or ones that are not really important)
>
> but the main reason i even have a clone is to sync updates in batches.
> it's really a hassle to keep servers in sync when changes to gentoo-x86
> happen any other minute. i also need to adapt my chef cookbooks for some
> updates, so i do it all in one batch (sync, test, adapt, test, deploy)
>

i forgot to add one main difference here: i only have ~1000 packages in my
repo, which makes it a lot faster for metadata, rsync, eix and all that ...
the repo is only used for server deployments. no desktop, no games, only
very few X11 ebuilds for headless testing etc.

[-- Attachment #2: Type: text/html, Size: 2399 bytes --]

Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/01/13 03:13 AM, Michael Weber wrote:
> 
> I wonder if anybody uses unattended [backup+]emerge as cron job. 
> I'm really temped to do so, but with users relying on these
> machines I'm always chicken-out.
> 

I used to, up until around 2006-2007 , at that point too many of my
emerge -uDN @world runs would fail in the middle and require user
intervention, so it became not worth it.

Perhaps once EAPI5 and sub-slots proliferate the tree, it'll be ready
to try again..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD5TU8ACgkQ2ugaI38ACPAGgQD7B1P6zsOxAXcYWIH5PRaVkWSD
s6h64Vid382u5vhgp8kBALSK2PpmIV4dMjM4SwC6eX9XAm0m3mblycXuRkxEccYa
=51W6
-----END PGP SIGNATURE-----