From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IUA4o-0003S8-P9 for garchives@archives.gentoo.org; Sat, 08 Sep 2007 23:50:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l88NhFLT005330; Sat, 8 Sep 2007 23:43:15 GMT Received: from dawn.lix-world.net (0x3e42aafc.adsl.cybercity.dk [62.66.170.252]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l88NfPPx003100 for ; Sat, 8 Sep 2007 23:41:25 GMT Received: from liferaft.lix-world.net ([10.0.0.4]) by dawn.lix-world.net with esmtp (Exim 4.63) (envelope-from ) id 1IU9vZ-0007sn-0I for gentoo-dev@lists.gentoo.org; Sun, 09 Sep 2007 01:41:25 +0200 Message-ID: <46E33324.4010805@lix-world.net> Date: Sun, 09 Sep 2007 01:41:24 +0200 From: Steen Eugen Poulsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; da; rv:1.8.1.6) Gecko/20070903 Thunderbird/2.0.0.6 ThunderBrowse/3.1.3 Mnenhy/0.7.5.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] USE flag how are they supposed to work? References: <46E3213E.5010307@lix-world.net> <46E325B8.2060605@gentoo.org> In-Reply-To: <46E325B8.2060605@gentoo.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050604010506000709030106" X-SA-Exim-Connect-IP: 10.0.0.4 X-SA-Exim-Mail-From: sep@lix-world.net X-SA-Exim-Scanned: No (on dawn.lix-world.net); SAEximRunCond expanded to false X-Archives-Salt: 53874e94-9d89-4803-acae-18d6dcdf4830 X-Archives-Hash: 92fe2bb9e747321cfdd6dcd6391f156f This is a cryptographically signed message in MIME format. --------------ms050604010506000709030106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Alistair Bush skrev: > * It is used by many different packages. yes, this is the rubber rule. It pretty much allows any use flag to be promoted to global when it has XX packages with it, the confusion comes because the number of package using a flag is no indication whatever you should set the flag globally or pr. package. Seem to me that the word global is used in the portage tree to mean one thing and then when we edit make.conf and /etc/portage we get another global/local meaning. > * It has a general non-specific purpose. Shouldn't that be "It has a general specific purpose". > The second point is important. If the effect of the thing USE flag upon > pkg-one is substantially different from the effect it has upon pkg-two, > then thing is not a suitable candidate for being made a global flag. In > particular, note that if client and server USE flags are ever > introduced, they can not be global USE flags for this reason. Again you seem to talk about specific purpose, but the quoted text say non-specific, excuse me for being confused. >> I'm trying to write a Replicator for /etc/portage and that leads me to >> work with USE flags, trying to design the replication of them among >> similar systems, but I can't find the golden set of rules for how best >> to apply USE flags. >> >> There seem to be a global/local USE flag system, but many so called >> global flags has duplicated description marking them as local flags, or >> they enable unneeded optional support. > > Unneeded by whom? The package in order for it to work. You don't need Java, Python, Perl, Lua, whatever scripting support in most packages. For most of the ones I've seen, I have to go write a Java/Python/Perl/Lua program, before I actually need it. > As for the duplicate local USE flags, They are most > probably redundant. > See above. Also note that you are not enabling support for pythonapi, > you are enabling support for python. Would you enable support for > linuxheaders when you are without a linux kernel. I don't understand what support for python is. > If that is the case, then I would suggest you search bugzilla and then > file a bug. Off course, but thats hardly the point of mentioning here, it was for bringing general attention to a ebuild mistake, that happens again and again. > See above. I can only assume that virtualbox doesn't need to have a > local alsa use flag. alsa: Adds support for media-labs/alsa-lib (Advanced Linux Sound Architecture) Local Flag: Enable support for ALSA instead of OSS (app-emulation/virtualbox) In box's case it's an "alsa not oss" flag, the global flag tend to be "also alsa", though I wont put my head on the block claiming it's always that meaning it has. >> As I see it, Gentoo's USE flag system is one of it's greatest strength, >> but at the moment seems like there is missing some overall design for >> how to implement USE flags, making it a lot harder to use USE flags, as >> there is no clear definition of global or local flags. The words is given different meaning depending on whatever I'm looking at the portage tree or working on configuring emerge. The portage trees global flag, is no indication whatever I should put the flag in USE="" in make.conf, in many cases a portage tree global flag is more an indication that I should use it locally pr. package. --------------ms050604010506000709030106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK7DCC BXIwggRaoAMCAQICBEOGqWgwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNV BAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDYwNzI2MTMyNTM1WhcNMDgwNzI2 MTM1NTM1WjB7MQswCQYDVQQGEwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sg dGlsa255dG5pbmcxQTAaBgNVBAMTE1N0ZWVuIEV1Z2VuIFBvdWxzZW4wIwYDVQQFExxQSUQ6 OTIwOC0yMDAyLTItMzE3NjE3NjE4MTQ5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDl v74PjpJrPTPfGCsZVhVK+ihTc1gLzPApQLuuAwFkU1YlotH5E92uO6YAGBh0u7Nu89N/N5Ad JV4v6Hsmr8CZRAm6K/Nib3QsIByUi8VdgCcfD/MPheu8nne/YYQ6Edws3M1vBvY22NHW7Hkd dtjYNiD2biGQ36eNoLbCTeMClwIDAQABo4ICyjCCAsYwDgYDVR0PAQH/BAQDAgP4MCsGA1Ud EAQkMCKADzIwMDYwNzI2MTMyNTM1WoEPMjAwODA3MjYxMzU1MzVaMIIBNwYDVR0gBIIBLjCC ASowggEmBgoqgVCBKQEBAQEDMIIBFjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZp a2F0LmRrL3JlcG9zaXRvcnkwgeIGCCsGAQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFu dmVuZGVsc2UgYWYgY2VydGlmaWthdGV0IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9D RVMgQ1AsIGRlciBrYW4gaGVudGVzIGZyYSB3d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5 LiBCZW3mcmssIGF0IFREQyBlZnRlciB2aWxr5XJlbmUgaGFyIGV0IGJlZ3LmbnNldCBhbnN2 YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEF BQcwAYYlaHR0cDovL29jc3AuY2VydGlmaWthdC5kay9vY3NwL3N0YXR1czAcBgNVHREEFTAT gRFzZXBAbGl4LXdvcmxkLm5ldDCBhAYDVR0fBH0wezBLoEmgR6RFMEMxCzAJBgNVBAYTAkRL MQwwCgYDVQQKEwNUREMxFDASBgNVBAMTC1REQyBPQ0VTIENBMRAwDgYDVQQDEwdDUkwxNDAz MCygKqAohiZodHRwOi8vY3JsLm9jZXMuY2VydGlmaWthdC5kay9vY2VzLmNybDAfBgNVHSME GDAWgBRgtYXsVmR+EhknZx1QFUtzrjv5EjAdBgNVHQ4EFgQUGnA0kYplEvpmQTxbkQMwljvV XMcwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIDqDANBgkqhkiG9w0BAQUF AAOCAQEAT5wZtMDaWA31Y7uOj4Z1YXx70TbIreJe1IdVGmQCb0X5LCapVCRHtnP0LEOOPZlJ WuR89jSRz8Ojxi+bR/maVu2bIlP900p+S18TksLsR1k7eiEPDYta8/rz7s5EHwuG00Ts9AiO 4nySH3ra/fqBh3HgUUQCbhLLPAB9YhvHGgxJpdzICzw2g9KzzCLsXqWaGCwb64K46CE9klOX UIFoQJ82HeJmjzsMy9ULY5c1JwKPbn8AzbxSOrQi3ssGOiuZQ51zqFfXckXGy9GPQigT/IWk 5sqzgVFmD1znzEl9+YITBfBSALKUdHxfkXu+UvOx+CjkWow4eSk/0QiF9DCZejCCBXIwggRa oAMCAQICBEOGqWgwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1RE QzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDYwNzI2MTMyNTM1WhcNMDgwNzI2MTM1NTM1 WjB7MQswCQYDVQQGEwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255 dG5pbmcxQTAaBgNVBAMTE1N0ZWVuIEV1Z2VuIFBvdWxzZW4wIwYDVQQFExxQSUQ6OTIwOC0y MDAyLTItMzE3NjE3NjE4MTQ5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlv74PjpJr PTPfGCsZVhVK+ihTc1gLzPApQLuuAwFkU1YlotH5E92uO6YAGBh0u7Nu89N/N5AdJV4v6Hsm r8CZRAm6K/Nib3QsIByUi8VdgCcfD/MPheu8nne/YYQ6Edws3M1vBvY22NHW7HkddtjYNiD2 biGQ36eNoLbCTeMClwIDAQABo4ICyjCCAsYwDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKA DzIwMDYwNzI2MTMyNTM1WoEPMjAwODA3MjYxMzU1MzVaMIIBNwYDVR0gBIIBLjCCASowggEm BgoqgVCBKQEBAQEDMIIBFjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZpa2F0LmRr L3JlcG9zaXRvcnkwgeIGCCsGAQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVs c2UgYWYgY2VydGlmaWthdGV0IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1As IGRlciBrYW4gaGVudGVzIGZyYSB3d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3m cmssIGF0IFREQyBlZnRlciB2aWxr5XJlbmUgaGFyIGV0IGJlZ3LmbnNldCBhbnN2YXIgaWZ0 LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYl aHR0cDovL29jc3AuY2VydGlmaWthdC5kay9vY3NwL3N0YXR1czAcBgNVHREEFTATgRFzZXBA bGl4LXdvcmxkLm5ldDCBhAYDVR0fBH0wezBLoEmgR6RFMEMxCzAJBgNVBAYTAkRLMQwwCgYD VQQKEwNUREMxFDASBgNVBAMTC1REQyBPQ0VTIENBMRAwDgYDVQQDEwdDUkwxNDAzMCygKqAo hiZodHRwOi8vY3JsLm9jZXMuY2VydGlmaWthdC5kay9vY2VzLmNybDAfBgNVHSMEGDAWgBRg tYXsVmR+EhknZx1QFUtzrjv5EjAdBgNVHQ4EFgQUGnA0kYplEvpmQTxbkQMwljvVXMcwCQYD VR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIDqDANBgkqhkiG9w0BAQUFAAOCAQEA T5wZtMDaWA31Y7uOj4Z1YXx70TbIreJe1IdVGmQCb0X5LCapVCRHtnP0LEOOPZlJWuR89jSR z8Ojxi+bR/maVu2bIlP900p+S18TksLsR1k7eiEPDYta8/rz7s5EHwuG00Ts9AiO4nySH3ra /fqBh3HgUUQCbhLLPAB9YhvHGgxJpdzICzw2g9KzzCLsXqWaGCwb64K46CE9klOXUIFoQJ82 HeJmjzsMy9ULY5c1JwKPbn8AzbxSOrQi3ssGOiuZQ51zqFfXckXGy9GPQigT/IWk5sqzgVFm D1znzEl9+YITBfBSALKUdHxfkXu+UvOx+CjkWow4eSk/0QiF9DCZejGCAiowggImAgEBMDkw MTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBEOG qWgwCQYFKw4DAhoFAKCCAUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDcwOTA4MjM0MTI0WjAjBgkqhkiG9w0BCQQxFgQUBrNQQY7RB9ReglnQXXkAedOv JYwwSAYJKwYBBAGCNxAEMTswOTAxMQswCQYDVQQGEwJESzEMMAoGA1UEChMDVERDMRQwEgYD VQQDEwtUREMgT0NFUyBDQQIEQ4apaDBKBgsqhkiG9w0BCRACCzE7oDkwMTELMAkGA1UEBhMC REsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBEOGqWgwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAYl+4UlnPtmi/zaoueIc8X BwYnEQfU99c0WGOK/YeXA9prUR0FzptdTW0o0C3ezv4jVOlVFbJ+tnE2q4wQ8bSfAGJy0+TX jp68xLKKqRQQt3tGMQ42j8ua/xHDX7cYzIPQnSm+wGR2KxQSb+9sZ6nVzXXuGv6osdNkCw2C HJJMUAAAAAAAAA== --------------ms050604010506000709030106-- -- gentoo-dev@gentoo.org mailing list