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. :) >> >>> 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. Until somebody posts a definitive list of which features we have compassion on, and which ones we don't, we should have compassion on anybody using standard portage features. It seems like when things go wrong with somebody's box the knee-jerk reaction is to say "well, you should be running daily emerge -alphabetsoup world" where alphabetsoup tends to vary by individual preference. I do recall some talk a few months ago about how it might not hurt to come up with a best-practices suggestion for doing regular upgrades, but it hasn't happened yet. I'm pretty sure -N was one of the items that was tossed around as a best practice. > 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. > 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. 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. 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. 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. Rich
