[gentoo-user] What's up with the "hardened" USE flag?

[gentoo-user] What's up with the "hardened" USE flag?

[Nikos Chantziaras]

After syncing, some heavy packages wanted to rebuild because of the 
"hardened" USE flag.  (I don't use the hardened profile, but they wanted 
to rebuild anyway.)  Really heavy stuff including libreoffice and 
firefox-5.  It took a few hours.  Then, next resync, and the same 
packages want to rebuild again because of the "hardened" USE flag :-/

Anyone else getting this?  These are big packages needing hours to get 
built.

Re: [gentoo-user] What's up with the "hardened" USE flag?

[meino.cramer]

Nikos Chantziaras <realnc@arcor.de> [11-07-04 04:08]:
> After syncing, some heavy packages wanted to rebuild because of the 
> "hardened" USE flag.  (I don't use the hardened profile, but they 
> wanted to rebuild anyway.)  Really heavy stuff including libreoffice 
> and firefox-5.  It took a few hours.  Then, next resync, and the same 
> packages want to rebuild again because of the "hardened" USE flag :-/
> 
> Anyone else getting this?  These are big packages needing hours to get 
> built.
> 
> 

Here the same...currently compiling :-/

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Daniel Pielmeier]

2011/7/4 Nikos Chantziaras <realnc@arcor.de>:
> After syncing, some heavy packages wanted to rebuild because of the
> "hardened" USE flag.  (I don't use the hardened profile, but they wanted to
> rebuild anyway.)  Really heavy stuff including libreoffice and firefox-5.
>  It took a few hours.  Then, next resync, and the same packages want to
> rebuild again because of the "hardened" USE flag :-/
>
> Anyone else getting this?  These are big packages needing hours to get
> built.

Everyone will get this. The culprit is a change in the
pax-utils.eclass [1]. Which adds USE="hardened to every consumer" of
the eclass. It changes nothing for non hardened users but forces a
rebuild of the affected packages. This unfortunate change was reverted
[2] shortly afterwards, so everybody who did the recompile including
me :)  has to do it again.

[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/pax-utils.eclass?r1=1.11&r2=1.12
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/pax-utils.eclass?r1=1.12&r2=1.13

-- 
Regards,
Daniel

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Andrea Conti]

Hello,

> Everyone will get this. The culprit is a change in the
> pax-utils.eclass [1]. Which adds USE="hardened to every consumer" of
> the eclass.

That's IUSE, not USE. USE flags are not touched (at least on
non-hardened systems), so the change is only picked up by emerge if you
use the --new-use option.

> It changes nothing for non hardened users but forces a
> rebuild of the affected packages.

If you're positively sure that a package's USE flags did not change
since when it was last compiled, you can avoid recompiling by adding (or
removing) the "hardened" flag in /var/db/pkg/<category>/<package>/IUSE.

andrea

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Daniel Pielmeier]

2011/7/4 Andrea Conti <alyf@alyf.net>:
> Hello,
>
>> Everyone will get this. The culprit is a change in the
>> pax-utils.eclass [1]. Which adds USE="hardened to every consumer" of
>> the eclass.
>
> That's IUSE, not USE. USE flags are not touched (at least on
> non-hardened systems), so the change is only picked up by emerge if you
> use the --new-use option.

IUSE~=USE [1]

>> It changes nothing for non hardened users but forces a
>> rebuild of the affected packages.
>
> If you're positively sure that a package's USE flags did not change
> since when it was last compiled, you can avoid recompiling by adding (or
> removing) the "hardened" flag in /var/db/pkg/<category>/<package>/IUSE.

Please do not use such hacks, use --changed-use to avoid a rebuild
instead of --new-use like Neil suggested.

Anyway the change in the eclass was reverted, so everything is fine again.

[1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html

-- 
Regards,
Daniel

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Andrea Conti]

>> That's IUSE, not USE.

> IUSE~=USE [1]

Um, yes. It's what I wrote.

[editing saved IUSE by hand]
> Please do not use such hacks

I know it's a hack, and I was not recommending it as a general-purpose
solution.

> use --changed-use to avoid a rebuild
> instead of --new-use like Neil suggested.

This only works if you *permanently* switch to --changed-use, otherwise
you'll just postpone things to next time you use --new-use.

> Anyway the change in the eclass was reverted, so everything is fine again.

Except for those who were lucky enough to do a sync+rebuild before the
change was reverted.

I'm not complaining, really, just stating things.

andrea

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Daniel Pielmeier]

2011/7/4 Andrea Conti <alyf@alyf.net>:
>
>>> That's IUSE, not USE.
>
>> IUSE~=USE [1]
>
> Um, yes. It's what I wrote.

Just wanted to state that the use flags _have changed_ because of the
IUSE="hardened" injection in the eclass. The whole changeset itself
has not effect for non hardened users but forcing a rebuild because of
changed flags.

I translate "That's IUSE, not USE" to IUSE!=USE
With "IUSE~=USE" I wanted to say that it is somewhat the same. IUSE is
a list of all USE flags including USE_EXPAND flags like
video_cards_smth but not arch flags like x86 or amd64.

Anyway if I do IUSE="FLAG" in an eclass this flag will show up in any
consumer of the eclass because it is cumulative and this forces a
rebuild with "--new-use".

>
>> use --changed-use to avoid a rebuild
>> instead of --new-use like Neil suggested.
>
>This only works if you *permanently* switch to --changed-use, otherwise
>you'll just postpone things to next time you use --new-use.

I know I am not a fan of --changed-use myself thus I accepted the
rebuild of openoffice,icedtea,thunderbird etc. and today I rebuild it
again :)

-- 
Regards,
Daniel

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Neil Bothwick]

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

On Mon, 4 Jul 2011 16:57:55 +0200, Daniel Pielmeier wrote:

> >> use --changed-use to avoid a rebuild
> >> instead of --new-use like Neil suggested.  
> >
> >This only works if you *permanently* switch to --changed-use, otherwise
> >you'll just postpone things to next time you use --new-use.  

I haven't used --new-use for years. What's the point of rebuilding
packages just because irrelevant USE flags have changed?

> I know I am not a fan of --changed-use myself

Why not? I see no downside to it but I'm willing to be educated.


-- 
Neil Bothwick

... if (pot.coffee == EMPTY) { programmer->brain = OFF };

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

[gentoo-user] Re: What's up with the "hardened" USE flag?

[Nikos Chantziaras]

On 07/05/2011 12:23 AM, Neil Bothwick wrote:
> On Mon, 4 Jul 2011 16:57:55 +0200, Daniel Pielmeier wrote:
>
>>>> use --changed-use to avoid a rebuild
>>>> instead of --new-use like Neil suggested.
>>>
>>> This only works if you *permanently* switch to --changed-use, otherwise
>>> you'll just postpone things to next time you use --new-use.
>
> I haven't used --new-use for years. What's the point of rebuilding
> packages just because irrelevant USE flags have changed?
>
>> I know I am not a fan of --changed-use myself
>
> Why not? I see no downside to it but I'm willing to be educated.

Imagine this:  A package is built by default with Gtk as well as with Qt 
support.  There is no USE flag which would omit building with one of 
those.  Then, the ebuild developer introduces those USE flags. 
--changed-use will not catch this, so you will continue having both Gtk 
and Qt support in the package, even though you're interested only in one 
of them (Gnome vs KDE user, for example).

Or, imagine another scenario.  A package offers multithreading support, 
resulting in a huge speed-up on machines with more than one core or CPU. 
  But the ebuild configures and builds the package without 
multithreading, and there's no USE flag.  When the ebuild dev puts a USE 
flag in there (and probably turns it on by default), --changed-use will 
also not catch this, because it's not a USE flag that changed, but 
instead a new one that wasn't there before.  So you will continue 
running the package in its slow built, missing out on the big 
performance gain.

I guess this is why people don't use --changed-use.  It won't catch 
cases like the above.

Re: [gentoo-user] Re: What's up with the "hardened" USE flag?

[Neil Bothwick]

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

On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote:

> > Why not? I see no downside to it but I'm willing to be educated.  
> 
> Imagine this:  A package is built by default with Gtk as well as with
> Qt support.  There is no USE flag which would omit building with one of 
> those.  Then, the ebuild developer introduces those USE flags. 
> --changed-use will not catch this, so you will continue having both Gtk 
> and Qt support in the package, even though you're interested only in
> one of them (Gnome vs KDE user, for example).
> 
> Or, imagine another scenario.  A package offers multithreading support, 
> resulting in a huge speed-up on machines with more than one core or
> CPU. But the ebuild configures and builds the package without 
> multithreading, and there's no USE flag.  When the ebuild dev puts a
> USE flag in there (and probably turns it on by default), --changed-use
> will also not catch this, because it's not a USE flag that changed, but 
> instead a new one that wasn't there before. So you will continue 
> running the package in its slow built, missing out on the big 
> performance gain.

changed-use also acts on added/removed flags, it just doesn't recompile
when the added/removed flag is not in use. So if my KDE system has -gtk
to use your first example, you are right in that adding a gtk USE flag
will not rebuild it until the next update and my program will continue to
work as it did. However, adding an enabled multithreading USE flag as
your second example will force a rebuild.

It seems that the trade off here is that I have may have cruft that was
previously compulsory but is now optional for a couple of weeks, but I
won't have to rebuild libreoffice or xulrunner every time a dev tweaks a
USE flag that doesn't affect me.

That seems a reasonable trade to me, but I still have an open mind.


-- 
Neil Bothwick

Top Oxymorons Number 2: Exact estimate

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

Re: [gentoo-user] Re: What's up with the "hardened" USE flag?

[Daniel Pielmeier]

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

Neil Bothwick schrieb am 05.07.2011 00:36:
> On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote:
> 
>>> Why not? I see no downside to it but I'm willing to be educated.
>>> 
>> 
>> Imagine this:  A package is built by default with Gtk as well as 
>> with Qt support.  There is no USE flag which would omit building 
>> with one of those.  Then, the ebuild developer introduces those
>> USE flags. --changed-use will not catch this, so you will continue
>>  having both Gtk and Qt support in the package, even though you're
>>  interested only in one of them (Gnome vs KDE user, for example).
>> 
>> Or, imagine another scenario.  A package offers multithreading 
>> support, resulting in a huge speed-up on machines with more than 
>> one core or CPU. But the ebuild configures and builds the package 
>> without multithreading, and there's no USE flag.  When the ebuild 
>> dev puts a USE flag in there (and probably turns it on by
>> default), --changed-use will also not catch this, because it's not
>> a USE flag that changed, but instead a new one that wasn't there
>> before. So you will continue running the package in its slow built,
>> missing out on the big performance gain.
> 
> changed-use also acts on added/removed flags, it just doesn't 
> recompile when the added/removed flag is not in use. So if my KDE 
> system has -gtk to use your first example, you are right in that 
> adding a gtk USE flag will not rebuild it until the next update and 
> my program will continue to work as it did. However, adding an 
> enabled multithreading USE flag as your second example will force a 
> rebuild.
> 
> It seems that the trade off here is that I have may have cruft that 
> was previously compulsory but is now optional for a couple of weeks, 
> but I won't have to rebuild libreoffice or xulrunner every time a dev
> tweaks a USE flag that doesn't affect me.
> 
> That seems a reasonable trade to me, but I still have an open mind.

The first scenario from Nikos seems valid but the second one with the
per default enabled USE flag will trigger a rebuild as --changed-use
only avoid rebuilds for disabled USE flags which are added or removed.

I personally can only think of another issue. There may be a completely
new use flag which you might want to enable. With --changed-use the
changes wont show up in the depgraph and you are not aware of the new
feature. You will only get them later when there is a version/revision bump.


These are all minor things and as you said it is a reasonable trade for
you to avoid useless rebuilds. Using --newuse instead of --changed-use
is just my personal preference. Many systems are idling around most of
the time, with --newuse they have to do something :)

-- 
Regards,
Daniel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] What's up with the "hardened" USE flag?

[Neil Bothwick]

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

On Mon, 04 Jul 2011 04:26:19 +0300, Nikos Chantziaras wrote:

> After syncing, some heavy packages wanted to rebuild because of the 
> "hardened" USE flag.  (I don't use the hardened profile, but they
> wanted to rebuild anyway.)  Really heavy stuff including libreoffice
> and firefox-5.  It took a few hours.  Then, next resync, and the same 
> packages want to rebuild again because of the "hardened" USE flag :-/

What profile and arch are you using? What arguments are you using to
emerge? I used to see this sort of behaviour occasionally with --newuse,
when it picked up USE flag changes unrelated to my system. Switching to
--changed-use stopped it, and I've not seen anything with hardened.


-- 
Neil Bothwick

A seminar on time travel will be held 2 weeks ago.

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