From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: USE flag question (not total newbie)
Date: Tue, 29 Nov 2016 11:51:56 +0200 [thread overview]
Message-ID: <7eec2d4f-72de-fa56-3893-bb47f54d61e9@gmail.com> (raw)
In-Reply-To: <20161129020950.15561.30AFAB04@matica.foolinux.mooo.com>
On 29/11/2016 04:15, Ian Zimmerman wrote:
> On 2016-11-29 01:55, Stroller wrote:
>
>>> [ebuild R ] dev-db/sqlitebrowser-3.8.0 USE="-qt5 {-test} (-qt4%*)"
>>>
>>> Does this mean the package will be rebuilt without any qt support at
>>> all? Why?
>>
>> No, I believe it means that the _option_ to enable or disable qt4 has
>> been removed.
>
> Well - notice the 'R'. So the package (or at least the version, see
> below) has not been changed since last time.
>
>> It could be that the package is always compiled with qt4, or that it's
>> always disabled, or that `make` detects it automatically. The best
>> things to look at are the ebuild and the changelog.
>
> There is no changelog for this package :-(
>
> In the ebuild, the only occurrence of the string "qt4" is:
>
> src_prepare() {
> # https://github.com/qingfengxia/qhexedit still bundled
> # x11-libs/qscintilla[qt4?,qt5?] still bundled
> # ^^^^
> find libs/{antlr-2.7.7,qcustomplot-source} -delete || die
> cmake-utils_src_prepare
> }
>
> I don't think this is responsible for the emerge output.
>
> Is it possible for the ebuild to change (in particular, for USE flags to
> be removed) without a change in version number?
>
Yes.
It's quite common to have a change in an ebuild that makes no difference
at all to the files on disk if it's already emerged. Bumping the version
in that case forces a rebuild everywhere to give exactly the same result
= not good.
If the package is not already merged on a given machine, then a new
install simply does what it should.
Suppose you had a situation where a package had qt4 in USE but because
of the way it works it's not actually possible to install it without
qt4. Merging it with USE=qt4 would always proceed, and with USE=-qt4
would always error out (you can get to this state gradually over time)
In that case, removing the flag entirely from USE would make zero
difference where the package is already installed, so no version bump is
needed.
All this depends on the judgement of the ebuild maintainer
--
Alan McKinnon
alan.mckinnon@gmail.com
next prev parent reply other threads:[~2016-11-29 9:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 1:34 [gentoo-user] USE flag question (not total newbie) Ian Zimmerman
2016-11-29 1:55 ` Stroller
2016-11-29 2:15 ` [gentoo-user] " Ian Zimmerman
2016-11-29 8:35 ` Neil Bothwick
2016-11-29 9:51 ` Alan McKinnon [this message]
2016-11-29 4:12 ` [gentoo-user] " J. Roeleveld
2016-11-29 4:59 ` [gentoo-user] " Ian Zimmerman
2016-11-29 8:37 ` Neil Bothwick
2016-11-29 12:26 ` Peter Humphrey
2016-11-29 12:48 ` Alan McKinnon
2016-11-29 18:36 ` Ian Zimmerman
2016-11-30 5:44 ` J. Roeleveld
2016-11-30 8:31 ` Ian Zimmerman
2016-11-30 9:40 ` J. Roeleveld
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=7eec2d4f-72de-fa56-3893-bb47f54d61e9@gmail.com \
--to=alan.mckinnon@gmail.com \
--cc=gentoo-user@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