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
On 01/18/2013 08:36 AM, Benedikt Böhm wrote:
On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber x...@gentoo.org
mailto:x...@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 x...@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
On Fri, Jan 18, 2013 at 9:13 AM, Michael Weber x...@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.
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
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 x...@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
On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@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
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
On Fri, Jan 18, 2013 at 2:13 PM, Benedikt Böhm hol...@gentoo.org wrote: On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@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.
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
-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-
Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes
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
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
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
-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 x...@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
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
-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
-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-
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
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 x...@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
On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber x...@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
Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes
On 01/15/2013 09:51 PM, Dirkjan Ochtman wrote: On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge pe...@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 x...@gentoo.org
Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes
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
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
-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
-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
-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
-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
-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 x...@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
On Wed, Jan 16, 2013 at 7:00 PM, Michael Weber x...@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
-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
On Tue, Jan 15, 2013 at 8:44 AM, Ian Stakenvicius a...@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
On Tue, Jan 15, 2013 at 3:03 PM, Rich Freeman ri...@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
-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 ri...@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
On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius a...@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
-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
-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 a...@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
On Tue, Jan 15, 2013 at 9:39 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius a...@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
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
On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge pe...@stuge.se wrote: We're halfway there; emerge --sync So how about adding: emerge --upgrade ? I was thinking the same thing! Cheers, Dirkjan
[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
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 + (UTC)
From: Ryan Hill (dirtyepic) dirtye...@gentoo.org
Reply-To: gentoo-dev@lists.gentoo.org, dirtye...@gentoo.org
To: gentoo-comm...@lists.gentoo.org
dirtyepic13/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 ChangesPath
1.615eclass/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.614r2=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 - 1.614
+++ ChangeLog 15 Jan 2013 02:30:53 - 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 dirtye...@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 e...@gentoo.org gnome2.eclass:
Allow ebuild override of eclass generated econf.
1.567eclass/toolchain.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.566r2=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.eclass29 Dec 2012 06:45:06 - 1.566
+++ toolchain.eclass15 Jan 2013 02:30:53 - 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 toolch...@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 x...@gentoo.org
