[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Rich Freeman posted on Fri, 20 Jan 2012 07:49:07 -0500 as excerpted: I'd still like to see our handbook include a recommended workflow for keeping gentoo up-to-date. Perhaps that should include a few options with the pros/cons of each. Agreed. I'd think that emerge -auDNv world would be one of those options. Perhaps another might be including build deps. One advantage of having people running a uniform update command that tends to keep everything up to date (even if not strictly necessary), is that it would cut down on the diversity of our install base. Right now a stable user could be running various versions of various libraries based on when they first merged them and whether they use -D, and so on. Keeping everybody moving along to newer versions (and more freshly compiled ones) could help to cut down on the bugs. Bugs filed with older versions still in portage would still be legitimate, but unless somebody really needs the older version there is no sense making more work for ourselves. From what I've gathered in various list discussions, etc, people running ~arch tend to like to run --deep (-D) as well. That would definitely include me. They're doing both for much the same reasons -- they like to be as upto date as possible. --newuse is in practice an extreme variant on the same theme, people who know what they're doing choose it when they want to stay as upto date as possible. Many stable users prefer /not/ to use --deep, again, for much the same reason they're using stable; they like the flexibility of gentoo, but much prefer something that just works with as little hassle and churn as possible, to chasing after the latest shiny version. Avoiding deep dependency updates is preferable for them, and they rely on gentoo masking and minimum dependencies on what they do update to keep things working. Of course, they'll want to stay even farther away from --newuse than from --deep, tho they might use it very occasionally as a troubleshooting tool for a specific package only, almost certainly with --pretend first, and they may not continue past that. This second group is never going to like --deep and will stay even further away from --newuse, but having a clear explanation of the alternatives and the groups they apply to in the handbook, much like I hope the above was, groupwise (I didn't explain the functionality), would be quite helpful indeed, helping to ensure users pick the best option for their needs. Not everybody reads the handbook for anything but the initial install, but that too is a handholding thing. As long as gentoo provides it, users get to do what they want, and if they choose not to read the handbook and end up with a broken system or in this case more likely just an extremely deoptimized for their needs gentoo updating workflow, well, they have the handbook available to read if they want; it's then their problem. (FWIW, I had read the handbook thru several times and was already helping people with problems on the list based on what I'd read, even before I had gentoo installed myself due to an issue with the then (2004) quite new NPTL. I never did get 2004.0 to install properly, but whether it was due to my experience with .0 or that there was a fix in 2004.1, /that/ installed properly, and I've been gentooing every since! =:^) I never could quite figure out the folks who were making it harder for themselves by not scouring that handbook to make the best use of their gentoo system possible, but they're certainly out there! Meanwhile, I'm still proud of the fact that I was able to help, for instance, people who lost their fstab due to not being careful with etc-update (fstab was handled like any other config file back then; if you selected replace with the new version, that's exactly what happened!), because I'd read the after all quite clear warnings on the subject, well before I got anywhere close to needing that info myself, and they obviously hadn't.) Perhaps this is worth its own thread, as this one is already drifting way off topic. =:^) -- 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: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
On Thu, Jan 19, 2012 at 08:56:57AM -0500, Rich Freeman wrote: So, suppose I don't want to update those 200 kde packages, but I don't want to ignore the odd package that does come up in -N in the future? Do I just run a daily emerge -puDN world, look at the output, then manually remove the 200 kde packages, and then run a manually-constructed emerge -1 with a bunch of individual packages on it? If anyone missed that, there's --exclude now and it was a simple --exclude=kde-base/* to skip those packages and wait for a better moment (like some important upgrade). Piotr Szymaniak. -- Mezczyzna odlozyl gazete z powrotem na stojak i postapil krok w przod, robiac mine, ktora nadala mu wyglad swinskiego pecherza rozpietego na drucianym wieszaku do garniturow. -- Graham Masterton, The Burning signature.asc Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Rich Freeman posted on Thu, 19 Jan 2012 08:56:57 -0500 as excerpted: On Thu, Jan 19, 2012 at 12:37 AM, Duncan 1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I think there is a legitimate issue with changing dependencies on stable ebuilds. If for whatever reason a mistake is made, you just broke tons of stable systems - especially if people rebuild with -N. The idea is that stuff goes through testing before it hits stable, which is why we call it stable. If you change stable directly, then it isn't stable. :) In theory at least, gentoo/kde has a rather firm policy that no change to either the ebuilds or the eclasses goes directly to tree (stable OR ~arch). Instead, it gets introduced into the overlay first, with several gentoo/kde devs and app-testers plus random brave/stupid-enough-to-run- overlay users like me testing it there, before it's introduced to the main tree, at all. Since from my observation at least, they're usually quite good about this, precisely BECAUSE of the possibility of mistakes you mention, and the costs of such a mistake especially for eclasses used by hundreds of packages, I'd be rather surprised if that didn't happen here. None-the-less, there are enough differences between overlay and the main tree, that such testing isn't likely to give 100% coverage. More importantly, many in-tree packages don't have such an overlay or if they do, such a strict test-in-overlay-first policy. AFAIK glibc is one such package and your point thus remains very valid in general and for that package (and eclasses), even if less so for projects like gentoo/kde with active overlays and strict overlay-first policies. I'm not going to complain much about a mere single package, glibc, triggering a -N rebuild. But I'm not going to complain about gentoo/kde doing it with 200-ish, either (way more if I had all of kde installed, I don't), for several reasons: 1) I'm not only running ~arch, I'm running the overlay. I'm running stable amd64 and the same kde issue directly hit stable. Oh, this is two days after the version bump hit stable - so that is 200 packages twice in two days. So, I will point out that this could have been better coordinated, although the extra rebuilds are harmless. Ouch! If that hit stable too, and was so uncoordinated with stabilizing whole kde versions that they stable-bumped two days before introducing this change, that changes the entire picture. Dd right were I a stable user I'd be complaining about that! (Even given the existence of the --exclude option mentioned elsewhere and below. You just don't do that to stable users for multi-hundred-package updates!) The USE flag was masked. But they knew a vote was coming on it and they could have either held up stabilizing for a couple extra days to coordinate it, or failing that, just left well enough alone /because/ the flag was masked, until they could drop it in coordination with the next mass stabilization. 3) Mike's right. The -N is simply available to give users a way to be notified of such changes if they wish to be, presumably thru use of -p or -a. So, suppose I don't want to update those 200 kde packages, but I don't want to ignore the odd package that does come up in -N in the future? Do I just run a daily emerge -puDN world, look at the output, then manually remove the 200 kde packages, and then run a manually-constructed emerge -1 with a bunch of individual packages on it? Obviously I'm just going to clench my teeth and run emerge -N anyway since spending 25 cpu-hours on pointless recompiles is less annoying than having those packages come up anytime I want to tweak a USE flag or whatever. Piotr mentions the helpful if AFAIK relatively new --exclude option, which I vaguely knew about but haven't actually had occasion to use, in part because my reaction is much like yours, knowing the change is there I'd rather grit my teeth and get it over with than wait. Even so, especially for multi-hundred-package projects like kde, it's a big deal, particularly for stable users, who presumably have chosen to use stable in part /because/ they don't want to be bothered with such things, far preferring that it just work by the time they get it and not to be bothered with unnecessary churn, even at the cost of being months or years behind, sometimes. But since it came up: @ Zac: Could the output of an emerge --pretend (or --ask) account for -newuse, and include a boilerplate sentence or so about --exclude, if the proposed package merge list includes any same-version remerges due to --newuse? Or if tracking --newuse packages is too much, just trigger the boilerplate if --newuse is among the passed (or default) options. @ gentoo/kde: Barring that or meanwhile,
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. I'd find that exactly right, here. However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. That's actually where I got the idea, after all. But I'm not going to argue it. I'd be more inclined to argue that we're already over the line in some places, and that if users really need this, they really should consider a different distribution as gentoo's obviously not right for them. So yeah, a mention of --exclude in the manpage's --newuse discussion sounds quite balanced, to me. =:^) -- 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: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? take a chill pill phil I see a violation of this rule at least on [glibc-]2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. Considering glibc was just one of some 200-ish packages I rebuilt early today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which will be in-overlay for just a few more days as 4.8-release is due next week, because gentoo/kde just removed the long-masked kdeenablefinal USE flag, which because it was masked (and I didn't unmask it) did NOT affect my kde as installed so I basically did the rebuild for nothing... I'm not going to complain much about a mere single package, glibc, triggering a -N rebuild. But I'm not going to complain about gentoo/kde doing it with 200-ish, either (way more if I had all of kde installed, I don't), for several reasons: 1) I'm not only running ~arch, I'm running the overlay. 2) I'm not only running the overlay, I'm deliberately unmasking and running upstream prereleases. But more important than either of those... 3) Mike's right. The -N is simply available to give users a way to be notified of such changes if they wish to be, presumably thru use of -p or -a. It DOESN'T mean they have to actually do the remerge, as they can either choose to ignore -N and not use it entirely, thus remaining blissfully unaware of such changes, or use it simply as notification, go look at the logs and see what the change was about, and decide based on that whether it's worth the remerge. I simply chose to do the 200+ package rebuild because I've learned that once I use -N to find out and investigate (which I do), after making any appropriate changes on my end, with a quad-core system, enough RAM to point PORTAGE_TMPDIR at tmpfs, and PORTAGE_NICENESS set to 19, it's simply easier to do the rebuild and not worry about it any more than it is to have to continue to mentally negate those changes every time I do the -N checks until I DO either rebuild or update. Plus, I look at it this way. It's winter here in Phoenix and while Phoenix isn't too cold, it was cold enough last nite that the extra computer heat from rebuilding a couple hundred packages didn't go to waste! =:^) If it were summer and I was having to run the AC to pump that heat outside, too, my decision may well have been different, especially since I'll already be updating to the full release when it comes out in a week or so. But then again maybe not, too, because I simply rest better when I know I'm all updated and my computer's all squared away with gentoo and the various overlays I follow. But either way, it's my decision, and I appreciate that Gentoo respects that and leaves the decision to me. =:^) That said, I also appreciate the care big projects like gentoo/kde normally take to synchronize such big changes to release, keywording and stabilization updates, as /either/ doing 200+ unnecessary rebuilds very often, or conversely, the constant tension of knowing I'm not fully synced if I continuously ignored -N packages, would get old rather fast. But for a single package, meh... -- 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
