[gentoo-dev] IUSE variable clarification

[gentoo-dev] IUSE variable clarification

[Burton Samograd]

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

Hi,

I'm curious about what the IUSE flag should be set to in an ebuild.
Does it contain all possible values that the package could use or
should it contain conditional type statements?  ie.  If a package
needs ncurses, and could possibly use ipv6 and socks5 as a configure
option should it be

IUSE="ncurses ipv6 socks5"

where in the src_conf section it contains:

use ipv6 && "${myconf} --enable-ipv6"
use socks5 && "${myconf} --enable-socks5"
etc.


or something different?

-- 
burton samograd
kruhft@kruhft.dyndns.org
http://kruhftwerk.dyndns.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] IUSE variable clarification

[Maik Schreiber]

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

> I'm curious about what the IUSE flag should be set to in an ebuild.
> Does it contain all possible values that the package could use or
> should it contain conditional type statements?  ie.  If a package
> needs ncurses, and could possibly use ipv6 and socks5 as a configure
> option should it be
> 
> IUSE="ncurses ipv6 socks5"

USE flags per definition define _optional_ features. So in your case, if the package _requires_ ncurses, you don't list it in IUSE (since you
don't even pay attention to the "ncurses" USE flag anyway).

-- 
Maik Schreiber, Gentoo Linux Developer   *   http://www.gentoo.org
mailto:blizzy@gentoo.org

GPG public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1F11D713        
Key fingerprint: CF19 AFCE 6E3D 5443 9599 18B5 5640 1F11 D713

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] IUSE variable clarification

[Nick Jones]

> I'm curious about what the IUSE flag should be set to in an ebuild.

It should contain _EVERY_ reference you make to a USE variable. So if
you check ncurses, it contains ncurses... if you check gtk, it contains
gtk. It's presently unused, but required for upcoming features like 
rebuild-on-use-change.

Nicholas Jones
Gentoo Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Terje Kvernes]

Nick Jones <carpaski@twobit.net> writes:

> It should contain _EVERY_ reference you make to a USE variable. So
> if you check ncurses, it contains ncurses... if you check gtk, it
> contains gtk. It's presently unused, but required for upcoming
> features like rebuild-on-use-change.

  isn't the IUSE-variable really redundant?  shouldn't portage be able
  to get the USE-flags directly from the ebuilds DEPEND-statement
  without adding an IUSE-kludge?  as far as I can tell IUSE just moves
  the work of maintaining this list from portage to the ebuild
  maintainer, who now has to update both DEPEND and IUSE.

  there is no doubt that portage needs the functionality IUSE
  provides, I'm just sceptical to the way that functionality is being
  provided.

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Felipe Ghellar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 553 bytes --]

Only use flags that require an additional package to be installed are 
listed in DEPEND/RDEPEND, and some do not (e.g. build, sse).

Terje Kvernes wrote:
>   isn't the IUSE-variable really redundant?  shouldn't portage be able
>   to get the USE-flags directly from the ebuilds DEPEND-statement
>   without adding an IUSE-kludge?

_______________________________________________________________________
Busca Yahoo!
O melhor lugar para encontrar tudo o que você procura na Internet
http://br.busca.yahoo.com/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Terje Kvernes]

Felipe Ghellar <fghellar2@yahoo.com.br> writes:

  (please quote properly)

> Terje Kvernes wrote:
>
> > isn't the IUSE-variable really redundant?  shouldn't portage be
> > able to get the USE-flags directly from the ebuilds
> > DEPEND-statement without adding an IUSE-kludge?
> 
> Only use flags that require an additional package to be installed
> are listed in DEPEND/RDEPEND, and some do not (e.g. build, sse).

  true enough, but do any of these flags give you any clues as to
  anything that needs to be rebuilt?

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1127 bytes --]

On Wednesday 08 January 2003 20:18, Terje Kvernes wrote:
> Nick Jones <carpaski@twobit.net> writes:
> > It should contain _EVERY_ reference you make to a USE variable. So
> > if you check ncurses, it contains ncurses... if you check gtk, it
> > contains gtk. It's presently unused, but required for upcoming
> > features like rebuild-on-use-change.
>
>   isn't the IUSE-variable really redundant?  shouldn't portage be able
>   to get the USE-flags directly from the ebuilds DEPEND-statement
>   without adding an IUSE-kludge?  as far as I can tell IUSE just moves
>   the work of maintaining this list from portage to the ebuild
>   maintainer, who now has to update both DEPEND and IUSE.
>
>   there is no doubt that portage needs the functionality IUSE
>   provides, I'm just sceptical to the way that functionality is being
>   provided.

Only depend would not suffice. Also all use <flag> commands should be taken 
into account. Ofcourse this "could" be done automatically, but it is more 
complex than a IUSE flag.

Paul

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] IUSE variable clarification

[Burton Samograd]

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

It looks to me like I got two different responses from different gentoo
developers:

> It should contain _EVERY_ reference you make to a USE variable. So if
> you check ncurses, it contains ncurses... if you check gtk, it contains
> gtk. It's presently unused, but required for upcoming features like
> rebuild-on-use-change.

> USE flags per definition define _optional_ features. So in your case,
> if the package _requires_ ncurses, you don't list it in IUSE (since you
> don't even pay attention to the "ncurses" USE flag anyway).

If the ebuild I'm writing has a depend line:

DEPEND="ncurses      # required
		ssl? libssl" # optional
	
according to the first response IUSE would be 

IUSE="ncurses ssl"

and for the second it would be:

IUSE="ssl"

Could someone please clarify?  It seems to me that the second is correct since
the first can already be inferred from the depend line, but if the compile on
USE change feature is only using the IUSE variable then the first would be
correct.

-- 
burton samograd
kruhft@kruhft.dyndns.org
http://kruhftwerk.dyndns.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: IUSE variable clarification

[Wilbert Berendsen]

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

On Thursday 09 January 2003 17:44, Burton Samograd wrote:
> It looks to me like I got two different responses from different gentoo
> (...)
> If the ebuild I'm writing has a depend line:
>
> DEPEND="ncurses      # required
> 		ssl? libssl" # optional
>
> according to the first response IUSE would be
>
> IUSE="ncurses ssl"
>
> and for the second it would be:
>
> IUSE="ssl"
>
> Could someone please clarify?  It seems to me that the second is correct
> since the first can already be inferred from the depend line, but if the
> compile on USE change feature is only using the IUSE variable then the
> first would be correct.

The second one is correct I think. I think of IUSE as Interactive USE. 
Interactive programs (eg Kportage) can read IUSE and immediately present the 
user the applicable flags before starting an emerge.

So IUSE contains only the used USE settings, not the dependencies.

bye,
Wilbert

- -- 
Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/)
To understand recursion, one must first understand recursion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+HarIx+vk367Vl7wRAs8KAJ9Wo8/XA5h7/s0TTkqABzfAF8E5YgCeMxSG
88TSMb0iKXCK22HZIY7jLII=
=upqa
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Maik Schreiber]

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

>> It should contain _EVERY_ reference you make to a USE variable. So if
>> you check ncurses, it contains ncurses... if you check gtk, it contains
>> gtk. It's presently unused, but required for upcoming features like
>> rebuild-on-use-change.
> 
> Could someone please clarify?  It seems to me that the second is correct since
> the first can already be inferred from the depend line, but if the compile on
> USE change feature is only using the IUSE variable then the first would be
> correct.

carpaski didn't make himself clear enough. What he means by "if you check ncurses", he really means "if you use the 'ncurses' USE flag". Which
in turn means that your ebuild can make _optional_ use of ncurses, but doesn't require it.

In any case, the ebuild in your example needs to have IUSE="ssl", _not_ IUSE="ncurses ssl", since it absolutely _requires_ ncurses. Again,
IUSE contains USE flags that the ebuild can make _optional_ use of.

-- 
Maik Schreiber, Gentoo Linux Developer   *   http://www.gentoo.org
mailto:blizzy@gentoo.org

GPG public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1F11D713        
Key fingerprint: CF19 AFCE 6E3D 5443 9599 18B5 5640 1F11 D713

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: IUSE variable clarification

[Maik Schreiber]

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

> The second one is correct I think. I think of IUSE as Interactive USE. 
> Interactive programs (eg Kportage) can read IUSE and immediately present the 
> user the applicable flags before starting an emerge.

AFAIK there is no complete definition of what the name "IUSE" means, but I'm pretty sure it means just that: "I use".

> So IUSE contains only the used USE settings, not the dependencies.

Correct.

-- 
Maik Schreiber, Gentoo Linux Developer   *   http://www.gentoo.org
mailto:blizzy@gentoo.org

GPG public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1F11D713        
Key fingerprint: CF19 AFCE 6E3D 5443 9599 18B5 5640 1F11 D713

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: IUSE variable clarification

[Yannick Koehler]

Le January 9, 2003 12:00 pm, Wilbert Berendsen a écrit:   /   On January 9, 
2003 12:00 pm, Wilbert Berendsen wrote:
> On Thursday 09 January 2003 17:44, Burton Samograd wrote:
> > It looks to me like I got two different responses from different gentoo
> > (...)
> > If the ebuild I'm writing has a depend line:
> >
> > DEPEND="ncurses      # required
> > 		ssl? libssl" # optional
> >
> > according to the first response IUSE would be
> >
> > IUSE="ncurses ssl"
> >
> > and for the second it would be:
> >
> > IUSE="ssl"
> >
> > Could someone please clarify?  It seems to me that the second is correct
> > since the first can already be inferred from the depend line, but if the
> > compile on USE change feature is only using the IUSE variable then the
> > first would be correct.
>
> The second one is correct I think. I think of IUSE as Interactive USE.
> Interactive programs (eg Kportage) can read IUSE and immediately present
> the user the applicable flags before starting an emerge.
>
> So IUSE contains only the used USE settings, not the dependencies.

Wouldn't it be interesting as well for portage/emerge to be able to display 
the content of the IUSE to the end-users?

For example, emerge -i vi could display the corresponding IUSE content so that 
a user can make a better choice when emerging that package?

-- 

Yannick Koehler


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Bob Phan]

* [Jan 09, 2003] Paul de Vrieze <gentoo-user@devrieze.net>:
> On Wednesday 08 January 2003 20:18, Terje Kvernes wrote:
> > Nick Jones <carpaski@twobit.net> writes:
> > > It should contain _EVERY_ reference you make to a USE variable. So
> > > if you check ncurses, it contains ncurses... if you check gtk, it
> > > contains gtk. It's presently unused, but required for upcoming
> > > features like rebuild-on-use-change.
> >
> > isn't the IUSE-variable really redundant?  shouldn't portage be
> > able to get the USE-flags directly from the ebuilds
> > DEPEND-statement without adding an IUSE-kludge?  as far as I can
> > tell IUSE just moves the work of maintaining this list from
> > portage to the ebuild maintainer, who now has to update both
> > DEPEND and IUSE.
> >
> > there is no doubt that portage needs the functionality IUSE
> > provides, I'm just sceptical to the way that functionality is
> > being provided.
> 
> Only depend would not suffice. Also all use <flag> commands should be
> taken into account. Ofcourse this "could" be done automatically, but
> it is more complex than a IUSE flag.
It shouldn't really be all that complex.  A simple re should be able to
parse out any contiguous word character string followed by a question
mark on a line.

That would grab a use var right out of depend.  My complaint isn't that
IUSE shouldn't exist, but that it shouldn't overlap the DEPENDs.
Redundancy like that just screams maintenence problems.  I think the way
that USE variable usage inside of ebuilds is handled should be more
similar to the way that they're presented to the user.  There are
multiple sources with priority to get an end list of USE variables.  To
grab the list of USE vars in the ebuild it should scan DEPEND and
RDEPEND, then append IUSE to it.  IUSE needn't contain anything that can
be placed in a DEPEND variable, instead it should _only_ contain USE
variables that are used, but aren't dependancies, like sse and mmx as
someone stated earlier.  This should be trivial to implement in python.

My two cents.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 * http://www.endlessrecursion.net/
 */

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] IUSE variable clarification

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1529 bytes --]

On Thursday 09 January 2003 22:05, Bob Phan wrote:
>
> That would grab a use var right out of depend.  My complaint isn't that
> IUSE shouldn't exist, but that it shouldn't overlap the DEPENDs.
> Redundancy like that just screams maintenence problems.  I think the way
> that USE variable usage inside of ebuilds is handled should be more
> similar to the way that they're presented to the user.  There are
> multiple sources with priority to get an end list of USE variables.  To
> grab the list of USE vars in the ebuild it should scan DEPEND and
> RDEPEND, then append IUSE to it.  IUSE needn't contain anything that can
> be placed in a DEPEND variable, instead it should _only_ contain USE
> variables that are used, but aren't dependancies, like sse and mmx as
> someone stated earlier.  This should be trivial to implement in python.

No DEPEND overlap is not clear either. That introduces a second place where 
information can be stored. Normally that is not good design. Second. I didn't 
talk about getting uses from DEPEND lines. Yes, that's easy. I was thinking 
about understanding shellscript on such a level that all invocations of use 
sse (where sse is an example of a DEPEND independant useflag) etc. are 
recognized to compose an IUSE flag.

Paul

ps. A validation tool that validates IUSE based on DEPEND is of course OK.
pps. The use function might also be adapted to through an error if the flag is 
not in IUSE

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] IUSE variable clarification

[Bob Phan]

* [Jan 09, 2003] Paul de Vrieze <gentoo-user@devrieze.net>:

<snip>

> pps. The use function might also be adapted to through an error if the flag is 
> not in IUSE
That would seem to be most ideal.  It would make sense if that was implemented
via the FEATURES variable, like sandboxing.

Anyway, most of what I said came from a standpoint that there are many many more
lines of ebuild code than portage code.  Any methods used to ease the maintenence
of that large base would benefit the stability of gentoo and the speed with which
it could move forward.

-- 
/*
 * Bob Phan <bob@endlessrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 * http://www.endlessrecursion.net/
 */

--
gentoo-dev@gentoo.org mailing list