public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gmail.com>
To: scarabeus@gentoo.org
Cc: gentoo-dev@lists.gentoo.org, chromium@gentoo.org
Subject: Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
Date: Fri, 11 Nov 2011 01:32:29 -0800	[thread overview]
Message-ID: <20111111093229.GA3812@localhost> (raw)
In-Reply-To: <CA+Nrkpf1q4d94RRAVYyqH9Qr41ipkMFW=bn22kTTJ+rc54tRNg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
> Hi guys,
> 
> In last 3 days i recompiled chromium 3x
> 
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag

<snip>

Chromium moves fast and you're obviously running unstable keywording.  
Meaning you're *intentionally* getting every beta channel release.

Nicely phrased, your complaint is that having ran unstable keywords, 
it's moving too fast for your taste.  Stable keywords seem like an 
obvious solution to it.

One thing that is less obvious is that there are essentially two 
flavors of unstable chromium- dev and beta.  Currently beta is 17.*, 
dev is 16.*.  If you don't want bleeding edge, but want faster than 
stable, pmask 17.*.

That said... you're complaining that having ran unstable, you're 
having to rebuild too much.  Stable exists for a reason.

Either way, I suggest folks flip through the changelog- not seeing 
anything egregious in bumping, refactoring appears to go out during 
upstream version bumps.

For the cups rebuild referenced above is a build compilation failure 
that was rolled out in existing versions (or in version bumps).  It 
may be an annoyance to Tommy that emerge -N picked it up, but for 
folks hitting the build failure, they obviously view it a bit 
differently (as evidenced by a fair amount of bitching on the bug in 
question).

If you really, really want to keep running bleeding edge, rebuilding 
for every change that occurs on it but selectively slowing down 
certain builds... well, patch portage and mangle the existing vcs 
rebuild code to be usable for other packages, adding a feature along 
the lines of "I want to run bleeding edge X, but rebuild it only 
weekly".

Barring that, the solutions for your user configuration problem are 
above.

~harring

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2011-11-11  9:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11  7:58 [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly Tomáš Chvátal
2011-11-11  8:22 ` Alec Warner
2011-11-11  8:45   ` Michał Górny
2011-11-11 14:44     ` Jeroen Roovers
2011-11-11 14:58       ` Michał Górny
2011-11-11 15:15         ` Jeroen Roovers
2011-11-11  9:21   ` Tomáš Chvátal
2011-11-11  9:32 ` Brian Harring [this message]
2011-11-11  9:48   ` Tomáš Chvátal
2011-11-11 10:39     ` Brian Harring
2011-11-11 12:35   ` Rich Freeman
2011-11-11 15:56   ` Nirbheek Chauhan
2011-11-11 17:28 ` [gentoo-dev] " Mike Gilbert
2011-11-11 17:57 ` [gentoo-dev] " "Paweł Hajdan, Jr."

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111111093229.GA3812@localhost \
    --to=ferringb@gmail.com \
    --cc=chromium@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=scarabeus@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox