Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
> On Sunday 04 November 2007, Zac Medico wrote:
>> For the USE=arch_${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
Well, for bug 133327 I was thinking that we should add an IUSE
syntax extension. For example, IUSE="@video_cards" would mean that
all the video_cards_* flags are in IUSE. I guess we could use a
similar approach for the implicit IUSE, and do something like
IUSE_IMPLICIT="@arch @elibc @kernel @userland" in the profile.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHLk7y/ejvha5XGaMRAtwvAKDwuGfybB8kyGCTgj3o4LfJ6BupagCfTvSO
mOj+WD2TSVu91WYslFAv1uQ=
=mtqq
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
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="${ARCH}" 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=${ARCH} *and* USE=arch_${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_${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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] 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="${ARCH}" 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=${ARCH} *and* USE=arch_${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_${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+CtPqjmI9g61TYgCg54/K
RFFucPFpdLUqnykuGKQz+3g=
=pNDU
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
[gentoo-portage-dev] Re: [gentoo-dev] Re: More general interface to use flags
On 11/4/07, Steve Long <[EMAIL PROTECTED]> wrote: > Marijn Schouten (hkBst) wrote: > > the current interface to use flags, useq, usev, use_with, use_enable, as > > defined in /usr/lib/portage/bin/ebuild.sh lacks generality. The common > > thing is testing a use flag and possibly echoing a string, but there is no > > function that implements this common behaviour. > > > > I propose that we add such a function. Proposed name for the function is > > "ifuse". > > > I like the overall API that is enabled (and that it doesn't break anything.) > > > I also propose to add the utility function "ifv" which is useful for > > writing concise and clean code. > > > This one seems a bit light-weight to me, but if it makes your life easier, > why not? > > One minor thing; -n is the default test, so: > [[ $1 ]] is the same as [[ -n $1 ]] > and: > [[ ! $1 ]] is the same as [[ -z $1 ]] > ''help test'' is very revealing, for those who haven't read it. ;-) Code Clarity over shortcuts. Use the explicit version. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
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="${ARCH}" 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=${ARCH} *and* USE=arch_${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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
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="${ARCH}" 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=${ARCH} *and* USE=arch_${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).
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
-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. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHLiXn/ejvha5XGaMRAqkTAJwMuxxMFaiAzQg4eqWWbLNZDQhiDACeKk5X GXRB/IRTLRFw7TygrVjW6tY= =o8mA -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
On Sunday 04 November 2007, Zac Medico wrote: > Fabian Groffen wrote: > > Just to have it clear and to be sure: > > > > On 04-11-2007 03:33:41 +, [EMAIL PROTECTED] wrote: > >> Modified: diffutils-2.8.7-r2.ebuild > >> Log: > >> do *not* include userland_GNU in IUSE > >> (Portage version: 2.1.3.16) > >> > >> > >> Index: diffutils-2.8.7-r2.ebuild > >> > >> -IUSE="nls static userland_GNU" > >> +IUSE="nls static" > > > > On 04-11-2007 08:10:29 +, Zac Medico wrote: > >> Author: zmedico > >> Date: 2007-11-04 08:10:29 + (Sun, 04 Nov 2007) > >> New Revision: 8420 > >> > >> Modified: > >>main/trunk/pym/portage/dbapi/bintree.py > >> Log: > >> When evaluating *DEPEND conditionals for the Packages metadata > >> index, do not use IUSE to filter USE since there is currently > >> no guarantee that IUSE properly defines all of the necessary > >> flags. > > > > These two changes now mean that without having "userland_GNU" in IUSE > > > > DEPEND="!userland_GNU? ( some/package )" > > > > will correctly end up in the Packages file, such that Portage will > > properly calculate dependencies when reading from a binhost, right? > > Well, I consider my change to be a workaround for people behaving > like Mike and refusing to declare certain conditionals in IUSE. The > way that I see it, userland_GNU is a USE conditional, so it belongs > in IUSE just like any other USE conditional. Maybe we would be > better off if things like userland_GNU weren't in the USE > conditional space, but they are. 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabian Groffen wrote: > Just to have it clear and to be sure: > > On 04-11-2007 03:33:41 +, [EMAIL PROTECTED] wrote: >> Modified: diffutils-2.8.7-r2.ebuild >> Log: >> do *not* include userland_GNU in IUSE >> (Portage version: 2.1.3.16) >> >> >> Index: diffutils-2.8.7-r2.ebuild > >> -IUSE="nls static userland_GNU" >> +IUSE="nls static" > > > On 04-11-2007 08:10:29 +, Zac Medico wrote: >> Author: zmedico >> Date: 2007-11-04 08:10:29 + (Sun, 04 Nov 2007) >> New Revision: 8420 >> >> Modified: >>main/trunk/pym/portage/dbapi/bintree.py >> Log: >> When evaluating *DEPEND conditionals for the Packages metadata >> index, do not use IUSE to filter USE since there is currently >> no guarantee that IUSE properly defines all of the necessary >> flags. > > These two changes now mean that without having "userland_GNU" in IUSE > > DEPEND="!userland_GNU? ( some/package )" > > will correctly end up in the Packages file, such that Portage will > properly calculate dependencies when reading from a binhost, right? Well, I consider my change to be a workaround for people behaving like Mike and refusing to declare certain conditionals in IUSE. The way that I see it, userland_GNU is a USE conditional, so it belongs in IUSE just like any other USE conditional. Maybe we would be better off if things like userland_GNU weren't in the USE conditional space, but they are. I don't understand why people refuse to declare certain conditionals in IUSE. IUSE conveys important information about which flags the package responds to. If we're not going to record them in IUSE explicitly, then every package, regardless of whether or not it uses those conditionals, will have to inherit them implicitly. If that's what we are going to do, then we should invent a way to declare in the profile which flags will behave that way (maybe we can just use USE_EXPAND_HIDDEN, but that's only designed for USE_EXPAND flags). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHLfk1/ejvha5XGaMRAqqIAKDiUJDeIXU9n+ikrRbk8rZNJ4Y0CwCbBSwH abNAp0Xoe8w5irwcZChgYEw= =PvYZ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
Just to have it clear and to be sure: On 04-11-2007 03:33:41 +, [EMAIL PROTECTED] wrote: > Modified: diffutils-2.8.7-r2.ebuild > Log: > do *not* include userland_GNU in IUSE > (Portage version: 2.1.3.16) > > > Index: diffutils-2.8.7-r2.ebuild > -IUSE="nls static userland_GNU" > +IUSE="nls static" On 04-11-2007 08:10:29 +, Zac Medico wrote: > Author: zmedico > Date: 2007-11-04 08:10:29 + (Sun, 04 Nov 2007) > New Revision: 8420 > > Modified: >main/trunk/pym/portage/dbapi/bintree.py > Log: > When evaluating *DEPEND conditionals for the Packages metadata > index, do not use IUSE to filter USE since there is currently > no guarantee that IUSE properly defines all of the necessary > flags. These two changes now mean that without having "userland_GNU" in IUSE DEPEND="!userland_GNU? ( some/package )" will correctly end up in the Packages file, such that Portage will properly calculate dependencies when reading from a binhost, right? -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
