public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
Date: Tue, 29 Jul 2014 02:41:06 +0000 (UTC)	[thread overview]
Message-ID: <pan$bda7d$e50034f1$78b6bf04$b2a47f8d@cox.net> (raw)
In-Reply-To: CA+CSuAJiQpsGqH-g-p_w6JiD-DezqJ6EJaNAXVVwdv9LNH4W8Q@mail.gmail.com

Denis Dupeyron posted on Mon, 28 Jul 2014 18:15:20 -0600 as excerpted:

> On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen <ssuominen@gentoo.org>
> wrote:
>> x265-1.2.ebuild:    KEYWORDS="~amd64 ~arm ~x86"
>> x265-1.3.ebuild:    KEYWORDS="~amd64 ~x86"
>> x265-9999.ebuild:   KEYWORDS="~amd64 ~x86"
>>
>> As in... You forgot to add ~arm to -9999.ebuild
> 
> Wait, what? Live ebuilds are keyworded now?

AFAIK, gentoo policy is that live ebuilds should always be masked so as 
never to be automatically pulled in without a deliberate unmasking of the 
live ebuild, but whether that's masked due to lack of keywords (ebuild), 
or due to hard-mask (package.mask) is I believe up to the maintainer.

For packages like this one where normal version-bumps start with the live 
ebuild (which after all should have been updated as development 
proceeded, upstream), simply copying it to the appropriate version-number 
ebuild, keeping it ~arch-keyworded on all archs where the non-live 
version is at least ~arch-keyworded, and using package.mask to force the 
masking, makes the most sense since then a version bump can literally 
amount to no more than an ebuild copy and manifest (tho obviously the 
maintainer will test it too, but ideally won't have to actually touch the 
content of the file).

-- 
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



  parent reply	other threads:[~2014-07-29  2:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140727190116.B09072004E@flycatcher.gentoo.org>
2014-07-28  6:41 ` [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild Samuli Suominen
2014-07-28  8:02   ` Samuli Suominen
2014-07-28 20:52     ` Markus Meier
2014-07-29  0:15   ` Denis Dupeyron
2014-07-29  0:49     ` Alex Xu
2014-07-29 13:33       ` Denis Dupeyron
2014-07-29  2:41     ` Duncan [this message]
2014-07-29 13:58       ` Denis Dupeyron
2014-07-30  9:38         ` Duncan
2014-07-30 11:48           ` Luis Ressel
2014-07-30 12:33             ` Samuli Suominen
2014-07-30 15:14               ` Luis Ressel
2014-07-30 17:29               ` Michael Haubenwallner
2014-07-30 17:33                 ` Samuli Suominen
2014-07-31  7:19                   ` Michael Haubenwallner
2014-07-30 20:15                 ` William Hubbs
2014-08-13  7:04             ` Tom Wijsman
2014-07-29 17:32     ` Samuli Suominen

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='pan$bda7d$e50034f1$78b6bf04$b2a47f8d@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.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