From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.105.134.102] (helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DiMZO-0006sO-Nt for garchives@archives.gentoo.org; Wed, 15 Jun 2005 01:19:55 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j5F1I5uV024720; Wed, 15 Jun 2005 01:18:05 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j5F1GDgG002972 for ; Wed, 15 Jun 2005 01:16:13 GMT Received: from smtp1.stealer.net ([82.165.37.24]) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DiMWX-00058K-Gb for gentoo-dev@lists.gentoo.org; Wed, 15 Jun 2005 01:16:57 +0000 Received: from sven by smtp1.stealer.net with local id 1DiMWW-0000Oa-CW for gentoo-dev@lists.gentoo.org from sender swegener@gentoo.org; Wed, 15 Jun 2005 01:16:56 +0000 Date: Wed, 15 Jun 2005 03:16:56 +0200 From: Sven Wegener To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] use.force support Message-ID: <20050615011655.GI4585@lightning.stealer.net> References: <20050613144048.GB4585@lightning.stealer.net> <42ADD039.6000009@gentoo.org> <46059ce10506131256c014866@mail.gmail.com> <20050613205041.GE4585@lightning.stealer.net> <42ADF5B9.6030202@egr.msu.edu> <20050613213812.GG4585@lightning.stealer.net> <42AF17EE.3090706@egr.msu.edu> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cf0hFtnykp6aONGL" Content-Disposition: inline In-Reply-To: <42AF17EE.3090706@egr.msu.edu> User-Agent: Mutt/1.5.8i X-Archives-Salt: d065aca0-119c-4019-9670-93c04b8506b6 X-Archives-Hash: 9399151e3bf1eaf12c45bd81878b0a5e --cf0hFtnykp6aONGL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2005 at 01:46:22PM -0400, Alec Warner wrote: > Sven Wegener wrote: > >On Mon, Jun 13, 2005 at 05:08:09PM -0400, Alec Warner wrote: > > > >>Sven Wegener wrote: > >> > >> > >>>use.force might not be the best name, but it's what we do with it for > >>>most of our users. Being able to -flag in /etc/portage/profile/use.for= ce > >>>is just because /etc/portage/profile gets added to the cascaded profile > >>>chain. Everything we add to portage that allows a profile to revert > >>>some behaviour added by parent profiles, can also be done with > >>>/etc/portage/profile and it's good that way. So, that we're able to > >>>-flag in use.force is just part of the way cascaded profiles work. It's > >>>not a feature that will be added just to support use.force. Primary > >>>reason for use.force is to have a way to activate flags even if USE=3D= "-*" > >>>is in make.conf or environment. > >> > >>How is this not just a consequence of USE=3D"-*"...that is what this do= es;=20 > >>turns off ALL use flags. How is use.force ( or the concept thereof )= =20 > >>not breaking the 'easy' interpretation of USE=3D"-*" because now things= =20 > >>aren't -*, they are -* + use.force things. > >> > >>It's one of those "if you use USE=3D"-*" you should know the consequenc= es=20 > >>of it...kind of deals. > > > > > >There are some USE flags that must survive the -* thing and already do > >it. One of them being ARCH, which is always there. And the USE_EXPANDed > >ones, the current important being being userland_*, kernel_* and elibc_* > >which are needed for special dependencies and checks. They are not to be > >modified by users by using USE in make.conf or the environment. They > >depend on the chosen profile and should always be enabled. We're not > >talking about every day USE flags, but really special USE flags, like > >multilib, selinux or the USE_EXPANDed ones that *must* be turned on for > >the chosen profile. Don't think of them like every day USE flags that > >allow you to tweak your system, they are used to pass some information > >from profiles to the ebuilds in a way portage can easily handle it. > > > >Hm, use.must sounds bad once I think about it more. > > > >Sven > > > I'm probably a little behind here, since this has been used for a while,= =20 > but I guess more discussion and ideas are good. >=20 > It seems like this is an abuse of USE flags, somewhat. I guess programs= =20 > could have support for elibc_X or elibc_Y or userland_GNU or=20 > userland_DARWIN/BSD but why a USE flag for these? If they must be=20 > forced, force them in the environment outside of USE flag usage. USE=20 > flags are for turning off optional support for programs, that is their=20 > overall purpose. There isn't a use flag for kernel version, there is a= =20 > function for that. Why is there not a function to determine=20 > userland/arch/libc? As Diegeo already wrote in his mail, the USE_EXPANDed ELIBC and KERNEL are also available as variables, but as variables we can't use them to enable or disable optional dependencies for specific kernels or libcs. Currently only USE flags are able to do it. I just had a quick look into our handbook[1] and it mentions the following definition for an USE flag: "Such a flag is a keyword that embodies support and dependency-information for a certain concept." And for sure, elibc_uclibc or kernel_linux stand for a certain concept. Same goes for multilib and selinux you mentioned further down in your mail. And they might have special dependency information and need special treatment in packages. IMHO they match the definition of USE flags just like any other USE flag we have. Even though, as I wrote in my previous mail, they are special, because they are not to be set or unset by users. You chose to activate them by chosing your profile. With use.force we're just making sure that they are actually enabled. We can give elibc_* or kernel_* another name, but in the end, they will serve the same purpose as USE flags and will be handled by portage in the same way. > In this case I think this use.force deal will create more complexity > in the USE flag area than help. This is not what use flags are for ( > also for multilib and SELINUX ). I don't see the complexity here. We're just creating a couple of files in our profiles that force some flags to be turned on. Sven=20 [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3D2&chap=3D= 2#doc_chap1_sect2 --=20 Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ --cf0hFtnykp6aONGL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCr4GHAXomK8S72HoRAuAtAJ9zo/IpA9+9Of6uHRkkpJcqATw3QwCcCo6b rd+eqasAHcTEok4xCpNrF0s= =b+Ke -----END PGP SIGNATURE----- --cf0hFtnykp6aONGL-- -- gentoo-dev@gentoo.org mailing list