Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On 11/04/2013 03:46 PM, Duncan wrote: Martin Vaeth posted on Mon, 04 Nov 2013 11:17:49 + as excerpted: Duncan 1i5t5.dun...@cox.net wrote: and the default is oneshot I would always recommend to put -1 into EMERGE_DEFAULT_OPTS; you can still use --select if you really want a new package in a word file: after the first installation this should happen rather rarely (and you can still use -n --select later on if you forgot it and realize that depclean wants to remove it). I imagine were emerge being written today, -1 /would/ be the default, and there'd be an option like --select to add to the @world file if necessary. That's actually the way I setup my scripts, with -1 the default, and an extra 2 suffix script variant that did add to the world file. But backward compatibility being what it is, I guess by the time portage authors realized they had a backward default, they couldn't really fix it, except by something like EMERGE_DEFAULT_OPTS. Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting You can use eix-sync for that [...] The advantage is that you will probably have a better behaviour in case some of the tasks fail... Again, if it were available (and something I knew about) back in the day... I might have ended up with that. However, I've come to appreciate an advantage to writing one's own scripts -- bug fixing or adding new functionality is a *LOT* easier since you're already familiar with the code. In fact, speaking from experience, adding support for a new feature to a script you've created yourself is often easier than figuring out the new config options for the same feature for an upstream script, when they add support for it! Plus, you don't have to worry about learning new config options for new features you'll never use, since you simply don't code them in the first place. =:^) The ebuild-patching tree and auto-redigest features were in fact recent adds, when I needed something that scaled better than one-off ebuild editing during the time gentoo/kde dropped support for USE=semantic- desktop and I had to carry my own patches to kill it. (FWIW, they've since reverted and offer USE=semantic-desktop again now, THANKS gentoo/kde! =:^) Similarly, adding git functionality to my existing kernel scripts wasn't difficult, and arguably easier to do since I knew the code, than trying to reverse engineer the new config options and perhaps the supporting code behind it, were I using an upstream solution that added git kernel support to existing helper scripts. I have a similar set, but starting with k* instead of e*, for automatic mainline kernel fetching, building, etc. This is rather cumbersome, since you should have different permissions for building and installing (if you use the recommended way to build into a separate KBUILD_OUTPUT with e.g. portage permissions). Except for fetching, you might want to use the kernel script from the mv overlay. Actually, both different building/installing permissions (via config file sudo option, tho I'll admit since I set that the option, running with that option turned off isn't tested, but the basic script infrastructure for it is there), and KBUILD_OUTPUT (setting in the config file) are already supported. =:^) And talk about ease of adding functionality, when I setup my 32-bit netbook build chroot, it was just a few lines changed in the kernel scripts themselves, and a dynamic config line added to the config file (which is sourced, so accepts both var=val style and dynamic config script snippets) to auto-detect which system I was building for and set KBUILD_OUTPUT accordingly, thereby keeping the work dirs and config entirely separate, automatically, via dynamic config. Trivial feature-add, and now that it's there, if I suddenly needed to scale to 100 or 1000 different kernel configs, that'd be even more trivial (even just a config file change), if necessary by having the config file source yet another separate-builds.conf file with its own dynamic-config logic to choose between the different configs. This sort of solidly sysadmin level helper/glue script is something Unix/ Linux/Gentoo is well optimized to make not only possible, but trivial, to implement, and I definitely put that feature to use! =:^) I'd be very interested in this kernel config script you have! I want to set up a mini ITX system as a NAS some day, and since it runs an Intel Atom, I'm likely going to be building the packages on my desktop.
[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as excerpted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 10:15 PM, yac wrote: On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Read the handbook lately? =:^) Handbook, part 2, Working with Gentoo, Chapter 1, A Portage Introduction, Doc_chapter 3, Maintaining Software (this is the amd64 link): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? part=2chap=1#doc_chap3 Look under the heading Updating your System. That starts with... emerge --update --ask world ... then discusses --deep, --withbdeps=y, and --newuse, so the example full update is ... emerge --update --deep --with-bdeps=y --newuse world --ask and --pretend are discussed in the same doc_chapter as well, as is -v (tho inconsistently, I don't see the long-option --verbose discussed, as it is for the others). --depclean, --search and --unmerge are discussed in that chapter too, as is gentoolkit with equery and revdep-rebuild. About the only thing missing is sets, and they're missing from working with portage (part 3) AFAICT as well, most likely because the handbooks simply haven't been updated for sets yet. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` This has been discussed before. Zac could give you a summary and possibly point you at the thread, I'm sure. I believe the reason it wasn't done is because the default options setting was added instead. Well that and the fact that (as covered below), I guess most users setup their own scripts/aliases at some point, at which point the existence of something that general-purpose default built-in becomes moot. You could emulate this yourself by setting up an environment variable to pass to emerge, or use an alias like I do: alias sysupdate='emerge -avuDN --with-bdeps=y @world' (Note: I should probably extend this to accept $1 args, in case I want to add `-t` or something) If you wanted something to cover more bases, you could make a script to do the above in addition to revdep-rebuild, python-updater, etc-update, and so on. Given the power and flexibility of portage/emerge and the extremely broad variety of needs that Gentoo meets, I believe it would be somewhat wasted work to add the option when users are already expected to read manpages and the Handbook. Perhaps -avuND should be made more obvious in a place or two in the documentation as a sort of compromise. ++ FWIW, I have a whole set of short, often 2-4 letter aliases/scripts that take care of the various options, as I'm lazy and find reaching for the - key difficult. Most of them are broken down into ea* and ep* variants, for ask and pretend, and the default is oneshot so as not to pollute the world file (which is normally empty anyway, as is @system for that matter as I negated it in my profile, everything's in sets, tho I sometimes use the worldfile as a sort of package purgatory when I want to try something out and keep it updated, but am not sure I want it in one of my permanent sets yet). Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting using a tree similar to the /etc/portage/patches/ tree, and does an automatic fetch deep world before its done. Then there's the ead (depclean) and ear (revdep-rebuild) variants, as well as epc to lookup changelogs, ept* for tree, and eal for @smart-live- rebuild. Completing the set are eup (etc-update) and envup (env-update). I have a similar set, but starting with k* instead of e*, for automatic mainline kernel fetching, building, etc. There are git-kernel commands and tarball-kernel commands, tho I've not used the latter in a few years so it could well be bitrotted. -- 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
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, 4 Nov 2013 09:51:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as excerpted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 10:15 PM, yac wrote: On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Read the handbook lately? =:^) Handbook, part 2, Working with Gentoo, Chapter 1, A Portage Introduction, Doc_chapter 3, Maintaining Software (this is the amd64 link): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? part=2chap=1#doc_chap3 Look under the heading Updating your System. That starts with... emerge --update --ask world ... then discusses --deep, --withbdeps=y, and --newuse, so the example full update is ... emerge --update --deep --with-bdeps=y --newuse world --ask and --pretend are discussed in the same doc_chapter as well, as is -v (tho inconsistently, I don't see the long-option --verbose discussed, as it is for the others). --depclean, --search and --unmerge are discussed in that chapter too, as is gentoolkit with equery and revdep-rebuild. About the only thing missing is sets, and they're missing from working with portage (part 3) AFAICT as well, most likely because the handbooks simply haven't been updated for sets yet. Yes, there is describes what are possible ways to update the system and what criteria goes into selection of the packages to update but not which one is recommended, generaly for regular update. Could be helpful for newbs and to avoid doubt even between more experienced users. I think only -u world could be used to do updates. (possible --with-bdeps could be recommended too, for better security until users find out about glsa-check, though I think it is limited to packages that are believed to be widely deployed. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` This has been discussed before. Zac could give you a summary and possibly point you at the thread, I'm sure. I believe the reason it wasn't done is because the default options setting was added instead. Well that and the fact that (as covered below), I guess most users setup their own scripts/aliases at some point, at which point the existence of something that general-purpose default built-in becomes moot. I expected some people to do this now, but I never found it worth anything unless it could deal with all the (perl|python|haskell|whatnot)-updaters and revdep-rebuild and such. It would be nice-to-have it as part of emerge for the reasons above and not having to You could emulate this yourself by setting up an environment variable to pass to emerge, or use an alias like I do: alias sysupdate='emerge -avuDN --with-bdeps=y @world' (Note: I should probably extend this to accept $1 args, in case I want to add `-t` or something) If you wanted something to cover more bases, you could make a script to do the above in addition to revdep-rebuild, python-updater, etc-update, and so on. Given the power and flexibility of portage/emerge and the extremely broad variety of needs that Gentoo meets, I believe it would be somewhat wasted work to add the option when users are already expected to read manpages and the Handbook. Perhaps -avuND should be made more obvious in a place or two in the documentation as a sort of compromise. ++ FWIW, I have a whole set of short, often 2-4 letter aliases/scripts that take care of the various options, as I'm lazy and find reaching for the - key difficult. Most of them are broken down into ea* and ep* variants, for ask and pretend, and the default is oneshot so as not to pollute the world file (which is normally empty anyway, as is @system for that matter as I negated it in my profile, everything's in sets, tho I sometimes use the worldfile as a sort of package purgatory when I want to try something out and keep it updated, but am not sure I want it in one of my permanent sets yet). Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting using a tree similar to the /etc/portage/patches/ tree, and does an automatic fetch deep world before its done. Then there's the ead (depclean) and ear (revdep-rebuild) variants, as well as epc to lookup changelogs, ept* for tree, and eal for @smart-live- rebuild. Completing the set are eup (etc-update) and envup (env-update). I have a similar set, but starting with
[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Duncan 1i5t5.dun...@cox.net wrote: and the default is oneshot I would always recommend to put -1 into EMERGE_DEFAULT_OPTS; you can still use --select if you really want a new package in a word file: after the first installation this should happen rather rarely (and you can still use -n --select later on if you forgot it and realize that depclean wants to remove it). (Also there is the world script from the mv overlay which, among other things, keeps/compares a backup of your world/world_set file, just in case...) Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting You can use eix-sync for that: If properly configured it handles tree and layman sync, eix-update (and eix-remote if required) and also has all sorts of hooks which can be used to call your patching/redigesting scripts; if you need an exceptional usage (e.g. to skip gentoo/layman syncing and/or the patching hooks) you can pass parameters to eix-sync. The advantage is that you will probably have a better behaviour in case some of the tasks fail... I have a similar set, but starting with k* instead of e*, for automatic mainline kernel fetching, building, etc. This is rather cumbersome, since you should have different permissions for building and installing (if you use the recommended way to build into a separate KBUILD_OUTPUT with e.g. portage permissions). Except for fetching, you might want to use the kernel script from the mv overlay.
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
yac wrote: On Mon, 4 Nov 2013 09:51:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as excerpted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 10:15 PM, yac wrote: On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Read the handbook lately? =:^) Handbook, part 2, Working with Gentoo, Chapter 1, A Portage Introduction, Doc_chapter 3, Maintaining Software (this is the amd64 link): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? part=2chap=1#doc_chap3 Look under the heading Updating your System. That starts with... emerge --update --ask world ... then discusses --deep, --withbdeps=y, and --newuse, so the example full update is ... emerge --update --deep --with-bdeps=y --newuse world --ask and --pretend are discussed in the same doc_chapter as well, as is -v (tho inconsistently, I don't see the long-option --verbose discussed, as it is for the others). --depclean, --search and --unmerge are discussed in that chapter too, as is gentoolkit with equery and revdep-rebuild. About the only thing missing is sets, and they're missing from working with portage (part 3) AFAICT as well, most likely because the handbooks simply haven't been updated for sets yet. Yes, there is describes what are possible ways to update the system and what criteria goes into selection of the packages to update but not which one is recommended, generaly for regular update. Could be helpful for newbs and to avoid doubt even between more experienced users. I think only -u world could be used to do updates. (possible --with-bdeps could be recommended too, for better security until users find out about glsa-check, though I think it is limited to packages that are believed to be widely deployed. But after a person has used Gentoo a while, they figure out what process leads to the most stable update process. They also figure out what defaults to add to make.conf as well. For that, it is as Duncan and Alan describe. Both have been using Gentoo for quite a while. I been using Gentoo for a good ten years. I installed from Gentoo 1.4 I think. Here is mine in make.conf: EMERGE_DEFAULT_OPTS=--with-bdeps y --backtrack=30 --keep-going -v -j10 --quiet-build=n -1 For my updates, I use this: emerge -uaDN world The only way to get a more stable system is to do a emerge -e world and update that way. At least that has been my experience so far. If Zac adds some other nifty feature, then I may add to the above as needed. For the past few years, that has resulted in as stable a system as I can get. I do from time to time run emerge -e world just for giggles when I have something acting odd and can't put my finger on the issue. Sometimes, that fixes it, sometimes not. Again, most of this comes from experience. The handbook explains it then the user figures it out from there. My $0.02 worth. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, 4 Nov 2013 11:26:32 +0100
yac y...@gentoo.org wrote:
On Mon, 4 Nov 2013 09:51:32 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
FWIW, I have a whole set of short, often 2-4 letter aliases/scripts
that take care of the various options
Sooo, basicly you have defined buttload of aliases, somehow managed to
remember these nonsensical names and actually did not save any
keystrokes, because most linux users heard of tab completion and use
it succesfuly to complete commands and their arguments. Cool story
bro.
Cool story guys.
Just like how MSOffice 2007 had tons of shortcuts to remember whereas
they got rid of that in MSOffice 2010 by intuitive context relevant
shortcuts; yet, people had memorized the shortcuts and are much quicker
than having to learn all the positions in the new intuitive Ribbon bar.
I didn't learn those shortcuts; so, I am quick with the Ribbon bar...
Or why do
ebuild name-1.ebuild clean manifest unpack
ebuild name-2.ebuild clean manifest unpack
diff -urN /var/tmp/portage/name-{1,2}/workdir/*
# ^ Actually, you would need to source S=... twice.
which requires a ton of tabs when I can just do `ediff 1 2`? I can
memorize it, but perhaps others need more short commands and can't.
You'll find out that people end up using both approaches; so, please
let's not get into detailed opinions, it is just a matter of choice.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, 04 Nov 2013 06:06:52 -0600 Dale rdalek1...@gmail.com wrote: But after a person has used Gentoo a while, they figure out what process leads to the most stable update process. Do they? What do you consider a stable update process? I come across users on a daily basis which - haven't upgraded their system lately because they're not good at it; - get into unclear slot conflicts locking them out of updates; - some build failure disallows their dependency graph from completing; - managed to finally update, but don't know about depclean; - managed to finally depclean, but don't know about eclean. It involves a lot of prior knowledge, manual checking and what in order to be able to update the system; I wouldn't label this stable, but rather dependent on the person updating it and to some extent even dependent on whether the person memorized all the docs and/or gets helped or get it told in the support channels. There are some improvements possible in these situations; I'm planning to discuss some ideas and write some patches where possible, and I hope other people jump on the bandwagon to help improve user experience. That doesn't mean I consider it bad or that we need to go hand holding. The only way to get a more stable system is to do a emerge -e world and update that way. At least that has been my experience so far. I have never needed this; I wonder whether there exists an example case for this, I only see this used when someone changes compiler / flags and wants to ensure the whole system turns into rice. * If Zac adds some other nifty feature, then I may add to the above as needed. For the past few years, that has resulted in as stable a system as I can get. I do from time to time run emerge -e world just for giggles when I have something acting odd and can't put my finger on the issue. Sometimes, that fixes it, sometimes not. Again, most of this comes from experience. The handbook explains it then the user figures it out from there. * http://funroll-loops.info/ -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, Nov 4, 2013 at 7:28 AM, Tom Wijsman tom...@gentoo.org wrote: On Mon, 04 Nov 2013 06:06:52 -0600 Dale rdalek1...@gmail.com wrote: But after a person has used Gentoo a while, they figure out what process leads to the most stable update process. Do they? What do you consider a stable update process? I come across users on a daily basis which... I would love to see a simple way to invoke emerge such that it just does the right thing in updating the system. Its behavior would always be considered subject to change (scripts should use the long options if they don't just want the latest automagic behavior). I see this as having several benefits: 1. It is newbie friendly. Anybody can understand apt-get update, apt-get upgrade. If I told you what I invoked to do my daily updates on Gentoo it would start a religious war on whether I'm doing it right. 2. It is supportable. If a developer pushes out a commit without a news item such that a stable user runs the standard update command before the commit and after it and the second update fails, then that is a valid bug. I'm not suggesting that all such bugs are preventable/etc, but it does help get rid of the whole you're holding it wrong debate. 3. It is maintainable. When new portage features arise they can be added to the default behavior when appropriate, without the need to get everybody to change their command lines. 4. It is a standard. Gentoo is all about being able to deviate from the standards. However, there is still value in suggesting a best practice. Rich
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Tom Wijsman wrote: On Mon, 04 Nov 2013 06:06:52 -0600 Dale rdalek1...@gmail.com wrote: But after a person has used Gentoo a while, they figure out what process leads to the most stable update process. Do they? What do you consider a stable update process? I consider it stable when things work as they should except for known bugs upstream. Obviously if there is a known bug upstream then that bug will likely filter right on through to Gentoo. That said, if the Gentoo devs can correct a issue, they do so but that is not always the case either. I come across users on a daily basis which - haven't upgraded their system lately because they're not good at it; - get into unclear slot conflicts locking them out of updates; - some build failure disallows their dependency graph from completing; - managed to finally update, but don't know about depclean; - managed to finally depclean, but don't know about eclean. It involves a lot of prior knowledge, manual checking and what in order to be able to update the system; I wouldn't label this stable, but rather dependent on the person updating it and to some extent even dependent on whether the person memorized all the docs and/or gets helped or get it told in the support channels. There are some improvements possible in these situations; I'm planning to discuss some ideas and write some patches where possible, and I hope other people jump on the bandwagon to help improve user experience. That doesn't mean I consider it bad or that we need to go hand holding. It does require prior knowledge which is why I said what I did. I used to do emerge -u world way back when. That would SOMETIMES lead to issues because it may not go deep enough. Then I added -D which helped but from time to time would still miss something. So, I added the backtrack to make.conf. That improved things even more. Over time, I realized that I needed to add the -N option so it got added to the command. As it is now, I have that knowledge. I learned some of that the hard way. You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. Right now, that has lead me to the most stable OS. When it doesn't, I do a emerge -e world if nothing else fixes the issue. That doesn't happen as much as it used to because either Zac is tweaking portage or devs are doing better on the ebuilds. Heck, it could be both since both need to work well to get a good end result. The only way to get a more stable system is to do a emerge -e world and update that way. At least that has been my experience so far. I have never needed this; I wonder whether there exists an example case for this, I only see this used when someone changes compiler / flags and wants to ensure the whole system turns into rice. * I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Obviously something fell through the cracks that my usual command would miss but the -e would catch since it does all packages. I never reported the issue since I don't know what specifically fixed the issue. There is no way for a person to figure out if it is a portage issue, ebuild issue or some other issue. I didn't see the point in filing a bug because there is no way to track down the source of the problem. This is my experience. By all means, if you do something different and it works for you, do it your way. I'm going to continue doing what works for me. If someone asks me how I do things, I'll recommend the same command/settings I use just like I'm sure some other old timers will do. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, 04 Nov 2013 14:02:28 -0600 Dale rdalek1...@gmail.com wrote: You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. And from there you can continue; like adding -vt --unordered-display and the list goes onto get a lot more detail, it can be handy to see what depends on what such that you don't look at a flat list wondering where a dependency came from. I haven't looked further at all the more specific parameters one can pass; but well, surely there's some objective and/or subjective improvement still possible there. I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Usually I debug / troubleshoot it for long enough to avoid that; but well, yeah, depending on the situation `emerge -e @world` could take a lot less time. Especially on a new Gentoo install where this might be more likely to happen as you often change things in the early days... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Tom Wijsman wrote: On Mon, 04 Nov 2013 14:02:28 -0600 Dale rdalek1...@gmail.com wrote: You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. And from there you can continue; like adding -vt --unordered-display and the list goes onto get a lot more detail, it can be handy to see what depends on what such that you don't look at a flat list wondering where a dependency came from. I haven't looked further at all the more specific parameters one can pass; but well, surely there's some objective and/or subjective improvement still possible there. The -v option is already in my make.conf file for portage but I do type it in out of habit sometimes. I do sometimes add -t if I think it will help. Sometimes it does, sometimes it doesn't. My point still remains, emerge -uaDN world has given me the most stable system so far. Removing any of those options results in issues and I end up going back to the command I should have used to begin with. I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Usually I debug / troubleshoot it for long enough to avoid that; but well, yeah, depending on the situation `emerge -e @world` could take a lot less time. Especially on a new Gentoo install where this might be more likely to happen as you often change things in the early days... When I run into a issue and post on -user and no one has a fix, I assume that I'm not going to find a fix on my own either. Duncan, Alan, Neil and others are MUCH more experienced than I am on the code part. So, if I need something fixed, emerge -e world may be the only option. Speed may not matter since anything else could still leave me with a not so stable issue. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Martin Vaeth posted on Mon, 04 Nov 2013 11:17:49 + as excerpted: Duncan 1i5t5.dun...@cox.net wrote: and the default is oneshot I would always recommend to put -1 into EMERGE_DEFAULT_OPTS; you can still use --select if you really want a new package in a word file: after the first installation this should happen rather rarely (and you can still use -n --select later on if you forgot it and realize that depclean wants to remove it). I imagine were emerge being written today, -1 /would/ be the default, and there'd be an option like --select to add to the @world file if necessary. That's actually the way I setup my scripts, with -1 the default, and an extra 2 suffix script variant that did add to the world file. But backward compatibility being what it is, I guess by the time portage authors realized they had a backward default, they couldn't really fix it, except by something like EMERGE_DEFAULT_OPTS. Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting You can use eix-sync for that [...] The advantage is that you will probably have a better behaviour in case some of the tasks fail... Again, if it were available (and something I knew about) back in the day... I might have ended up with that. However, I've come to appreciate an advantage to writing one's own scripts -- bug fixing or adding new functionality is a *LOT* easier since you're already familiar with the code. In fact, speaking from experience, adding support for a new feature to a script you've created yourself is often easier than figuring out the new config options for the same feature for an upstream script, when they add support for it! Plus, you don't have to worry about learning new config options for new features you'll never use, since you simply don't code them in the first place. =:^) The ebuild-patching tree and auto-redigest features were in fact recent adds, when I needed something that scaled better than one-off ebuild editing during the time gentoo/kde dropped support for USE=semantic- desktop and I had to carry my own patches to kill it. (FWIW, they've since reverted and offer USE=semantic-desktop again now, THANKS gentoo/kde! =:^) Similarly, adding git functionality to my existing kernel scripts wasn't difficult, and arguably easier to do since I knew the code, than trying to reverse engineer the new config options and perhaps the supporting code behind it, were I using an upstream solution that added git kernel support to existing helper scripts. I have a similar set, but starting with k* instead of e*, for automatic mainline kernel fetching, building, etc. This is rather cumbersome, since you should have different permissions for building and installing (if you use the recommended way to build into a separate KBUILD_OUTPUT with e.g. portage permissions). Except for fetching, you might want to use the kernel script from the mv overlay. Actually, both different building/installing permissions (via config file sudo option, tho I'll admit since I set that the option, running with that option turned off isn't tested, but the basic script infrastructure for it is there), and KBUILD_OUTPUT (setting in the config file) are already supported. =:^) And talk about ease of adding functionality, when I setup my 32-bit netbook build chroot, it was just a few lines changed in the kernel scripts themselves, and a dynamic config line added to the config file (which is sourced, so accepts both var=val style and dynamic config script snippets) to auto-detect which system I was building for and set KBUILD_OUTPUT accordingly, thereby keeping the work dirs and config entirely separate, automatically, via dynamic config. Trivial feature-add, and now that it's there, if I suddenly needed to scale to 100 or 1000 different kernel configs, that'd be even more trivial (even just a config file change), if necessary by having the config file source yet another separate-builds.conf file with its own dynamic-config logic to choose between the different configs. This sort of solidly sysadmin level helper/glue script is something Unix/ Linux/Gentoo is well optimized to make not only possible, but trivial, to implement, and I definitely put that feature to use! =:^) -- 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
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Duncan wrote: I believe the reason it wasn't done is because the default options setting was added instead. Well that and the fact that (as covered below), I guess most users setup their own scripts/aliases at some point, at which point the existence of something that general-purpose default built-in becomes moot. Not if the built-in code saves a meaningful bit of code for each user. //Peter
[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
yac posted on Mon, 04 Nov 2013 11:26:32 +0100 as excerpted: Sooo, basicly you have defined buttload of aliases, somehow managed to remember these nonsensical names and actually did not save any keystrokes, because most linux users heard of tab completion and use it succesfuly to complete commands and their arguments. Cool story bro. Such nonsense puts me in good company, given nonsense such as mv cp and rm, in the best Unix tradition! So thanks for the compliment! =:^) Just as beginner Unix admins /think/ move when they type mv, until mv becomes its own concept and thinking move is the long way around, I /thought/ emerge ask world when I typed eaw, until familiarity made eaw the normal concept, and emerge --ask (-NuDv) @world became the long way around I seldom gave much thought to any longer. As for tab-completion, it only takes a bit of shell-script to add the tab- completion already available for emerge, to my ea*/ep* variants as well, and they're tab-completed with (other) options and package names exactly as if I had typed/completed out the longer form. Drop that in the same autocomplete location and I'm good to go! =:^) Nobody says you have to use it, and I was in fact arguing that everybody develops their own such shortcuts over time. My solution's not for everybody and apparently not for you, but that's fine, because it's uniquely custom designed for me! =:^) But what makes Unix/Linux/Gentoo great is that this same level of unique custom design is available and exposed to everyone, for their own use as they see fit. =:^) -- 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
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On 04/11/2013 14:28, Tom Wijsman wrote: The only way to get a more stable system is to do a emerge -e world and update that way. At least that has been my experience so far. I have never needed this; I wonder whether there exists an example case for this, I only see this used when someone changes compiler / flags and wants to ensure the whole system turns into rice. * I've used this once or twice over the years to take care of inexplicable instability, the last time being right in the middle of kmail2/akonadi upheaval. I think it was in the KDE4.4 days. I strongly suspect the actual cause was inconsistencies around plug-in modules - the only thing I know of that portage and tools like revdep-rebuild can't really detect. I must stress that it's an exceptionally blunt hammer of a tool and not to be used lightly. It's really the very very last resort, only suitable when the cost of my troubleshooting time is more than the cost of cpu cycles over a weekend. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On 11/04/2013 04:46 PM, Duncan wrote: I imagine were emerge being written today, -1 /would/ be the default, and there'd be an option like --select to add to the @world file if necessary. That's actually the way I setup my scripts, with -1 the default, and an extra 2 suffix script variant that did add to the world file. But backward compatibility being what it is, I guess by the time portage authors realized they had a backward default, they couldn't really fix it, except by something like EMERGE_DEFAULT_OPTS. Actually, this behavior has flipped back and forth three or four times (silently!), to the detriment of my @world sets. The last time I brought it up was in, https://bugs.gentoo.org/show_bug.cgi?id=397313 but you can chase the bug trail back to 2004. There are plenty of people on both sides. I haven't changed my mind, but the problem is solved here. I spend hours writing metapackages for the things that I want recorded in @world so that they can be differentiated from the things that were --updated without --oneshot (which is easy to forget). The servers that were alive during the silent changes in behavior were physically retired.
[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Michael Orlitzky posted on Mon, 04 Nov 2013 20:23:17 -0500 as excerpted: On 11/04/2013 04:46 PM, Duncan wrote: I imagine were emerge being written today, -1 /would/ be the default, and there'd be an option like --select to add to the @world file if necessary. That's actually the way I setup my scripts Actually, this behavior has flipped back and forth three or four times (silently!), to the detriment of my @world sets. I guess that demonstrates the degree to which I use my scripts, as I wasn't even aware of that... [T]he problem is solved here. I spend hours writing metapackages for the things that I want recorded in @world so that they can be differentiated from the things that were --updated without --oneshot (which is easy to forget). I jumped on sets for that, putting everything in sets and checking the world file occasionally so that if there's anything it it at all, it's either because I put it there specifically as a package purgatory, or because I forgot... but evidently I've used my scripts so consistently that I've never forgotten., as I've yet to find anything there I didn't deliberately put in package purgatory. Actually, I ended up using sets back when I setup my netbook, as I needed some way to sort thru the main machine's world file and figure out what listings I wanted for the netbook and which not, and I was familiar with the then new sets feature from the kde overlay, and decided sets were the perfect way to category-sort everything, figuring out what I wanted on the netbook at the same time. I don't update the netbook anything even close to as consistently, however, often ending up going a year or even two between updates (security isn't a big issue as I deliberately keep anything sensitive off the netbook already, and use it more offline than as as a NETbook in any case), but because I keep the sets identical except for #-commenting a package here or there on one side or the other, when I /do/ update it's a relatively simple matter to diff the sets along with the use file (separate and sourced from make.conf) and package.* files, updating the netbook's files based on the main machine's files as I go. Then it's mostly a matter of iteratively updating what can be updated, skipping what can't as the jump is too large and other packages need updated first, dealing with the problems one at a time, until everything updated and I can once again do an emerge empty-tree world without issue. -- 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
