Re: IUSE and userland_, elibc_, kernel_, etc.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Sunday 04 November 2007, Andrew Gaffney wrote:
>> Zac Medico wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Mike Frysinger wrote:
>>>> userland_* and all other profile-expanded
USE flags are "magical" and
>>>> arent available for user consumption.  that
is how i view IUSE.  it was
>>>> my understanding that portage was going to
get fixed to automatically
>>>> include the profile-expanded ones and so
adding anything to IUSE now for
>>>> ebuilds is dumb when they're just going to
get turned around and
>>>> removed.  the same goes for all
implicit/automatic USE expanding things.
>>>>  portage can do this for us, so having
developers track it themselves
>>>> seems like a waste of time. -mike
>>> Fair enough, but we need to define a way to
"automatically include
>>> the profile-expanded ones" since none
currently exists. One thing
>>> that I don't like about using USE_EXPAND_HIDDEN
is that ARCH isn't a
>>> USE_EXPAND.  It would have been more consistent
if it had been,
>>> along with KERNEL, ELIBC, and USERLAND.
>> Why not turn it into one? The whole
USE="$" thing is inconsistent
>> with the USE_EXPANDed KERNEL, ELIBC, AND USERLAND.
Yes, I know that it's
>> been around a lot longer than the others, but
that's not a good reason for
>> keeping it the way it is.
>>
>> I don't think it would be a difficult transition.
Is there any reason that
>> portage can't set both USE=$ *and*
USE=arch_$ for a while
>> (until all ebuilds have been changed to use the new
USE_EXPANDed form)? We
>> could even just have portage set both forms
indefinitely (the old form does
>> no harm if nothing is using it).
> 
> an interesting line of thinking and quite logical ... i
dont see any arguments 
> against it other than "it's always been this
way" and considering the 
> advantages for everyone, i dont think that offsets the
pros
> -mike

For the USE=arch_$ part, we only have to add ARCH to
USE_EXPAND in the base profile. For generating the implicit
IUSE, we
can introduce a new profile variable (rather than hardcode
them).
For example, we can define IUSE_EXPAND_IMPLICIT="ARCH
ELIBC KERNEL
USERLAND" and that will cause every package to inherit
the
corresponding USE_EXPAND flags in it's IUSE.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHLkrj/ejvha5XGaMRAmC4AJ9bnhm3lysB/2V+CtPqjmI9g61TYgCg
54/K
RFFucPFpdLUqnykuGKQz+3g=
=pNDU
-----END PGP SIGNATURE-----
-- 
gentoo-portage-devgentoo.org mailing list

ON SUNDAY 04 NOVEMBER 2007, ZAC MEDICO WROTE:
> MIKE FRYSINGER WROTE:
> > ON SUNDAY 04 NOVEMBER 2007, ANDREW GAFFNEY WROTE:
> >> ZAC MEDICO WROTE:
> >>> MIKE FRYSINGER WROTE:
> >>>> USERLAND_* AND ALL OTHER
PROFILE-EXPANDED USE FLAGS ARE "MAGICAL" AND
> >>>> ARENT AVAILABLE FOR USER CONSUMPTION. 
THAT IS HOW I VIEW IUSE.  IT
> >>>> WAS MY UNDERSTANDING THAT PORTAGE WAS
GOING TO GET FIXED TO
> >>>> AUTOMATICALLY INCLUDE THE
PROFILE-EXPANDED ONES AND SO ADDING ANYTHING
> >>>> TO IUSE NOW FOR EBUILDS IS DUMB WHEN
THEY'RE JUST GOING TO GET TURNED
> >>>> AROUND AND REMOVED.  THE SAME GOES FOR
ALL IMPLICIT/AUTOMATIC USE
> >>>> EXPANDING THINGS. PORTAGE CAN DO THIS
FOR US, SO HAVING DEVELOPERS
> >>>> TRACK IT THEMSELVES SEEMS LIKE A WASTE
OF TIME. -MIKE
> >>>
> >>> FAIR ENOUGH, BUT WE NEED TO DEFINE A WAY
TO "AUTOMATICALLY INCLUDE
> >>> THE PROFILE-EXPANDED ONES" SINCE NONE
CURRENTLY EXISTS. ONE THING
> >>> THAT I DON'T LIKE ABOUT USING
USE_EXPAND_HIDDEN IS THAT ARCH ISN'T A
> >>> USE_EXPAND.  IT WOULD HAVE BEEN MORE
CONSISTENT IF IT HAD BEEN,
> >>> ALONG WITH KERNEL, ELIBC, AND USERLAND.
> >>
> >> WHY NOT TURN IT INTO ONE? THE WHOLE
USE="$" THING IS INCONSISTENT
> >> WITH THE USE_EXPANDED KERNEL, ELIBC, AND
USERLAND. YES, I KNOW THAT IT'S
> >> BEEN AROUND A LOT LONGER THAN THE OTHERS, BUT
THAT'S NOT A GOOD REASON
> >> FOR KEEPING IT THE WAY IT IS.
> >>
> >> I DON'T THINK IT WOULD BE A DIFFICULT
TRANSITION. IS THERE ANY REASON
> >> THAT PORTAGE CAN'T SET BOTH USE=$ *AND*
USE=ARCH_$ FOR A
> >> WHILE (UNTIL ALL EBUILDS HAVE BEEN CHANGED TO
USE THE NEW USE_EXPANDED
> >> FORM)? WE COULD EVEN JUST HAVE PORTAGE SET
BOTH FORMS INDEFINITELY (THE
> >> OLD FORM DOES NO HARM IF NOTHING IS USING
IT).
> >
> > AN INTERESTING LINE OF THINKING AND QUITE LOGICAL
... I DONT SEE ANY
> > ARGUMENTS AGAINST IT OTHER THAN "IT'S ALWAYS
BEEN THIS WAY" AND
> > CONSIDERING THE ADVANTAGES FOR EVERYONE, I DONT
THINK THAT OFFSETS THE
> > PROS
>
> FOR THE USE=ARCH_$ PART, WE ONLY HAVE TO ADD ARCH
TO
> USE_EXPAND IN THE BASE PROFILE. FOR GENERATING THE
IMPLICIT IUSE, WE
> CAN INTRODUCE A NEW PROFILE VARIABLE (RATHER THAN
HARDCODE THEM).
> FOR EXAMPLE, WE CAN DEFINE
IUSE_EXPAND_IMPLICIT="ARCH ELIBC KERNEL
> USERLAND" AND THAT WILL CAUSE EVERY PACKAGE TO
INHERIT THE
> CORRESPONDING USE_EXPAND FLAGS IN IT'S IUSE.

I CONSIDER PROFILE ONES HALF THE SOLUTION ... WHAT ABOUT THE
OTHER USE 
EXPANDED ONES ?  VIDEO CARDS / ALSA DRIVERS / ETC...
-MIKE