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. D****d 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, since getting that implemented and stabilized in portage could take a bit... what about putting an e* message mentioning portage's --exclude option in at least kdelibs' pkg_pretend? I believe run from there, it can test and trigger only on --newuse invocation, and doing it only for kdelibs should hit at least the rebuild-all-of-kde cases without spamming, as doing it for every kde package would certainly do. > All that said, the kde change is harmless and while it would have been > better to coordinate it (or just introduce it in the next version), > worse things could go wrong. Agreed. > I'm more concerned about the tendency to introduce flags in our package > manager, have them get promoted in various forums, and then have people > more-or-less rebuked for using them. There is no problem in having > flags that shouldn't be routinely used, but man pages and such should > clearly indicate when this is the case (as is the case with --unmerge > and so on). If we don't warn people not to use a flag, > we shouldn't punish them when they do. Agreed in general. In the case of --newuse, tho, the above suggested boilerplate message mentioning --exclude would probably go quite some way toward dealing with the situation. Are there other such emerge flags (other than the corresponding -N) where a boilerplate message mentioning --exclude would be useful? What about other boilerplate messages for other options? -- 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
