Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
* Zac Medico [EMAIL PROTECTED] [2008-08-25 20:42]: Obviously there are an infinite number of possible approaches. The main reason I brought this up was that a user had expressed a desire to have package.keywords for use in private profiles (not the official gentoo ones). The question of whether or not we should implement package.keywords for the sake of private profiles should be considered separately from the question of whether or not we choose a policy to allow the use of package.keywords in one or more of our official gentoo profiles. I'm currently in need of package.keywords for private profiles as well, so please add me to the list :) Would be great if portage-2.2 final would support that! Thanks, Wolfram
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
В Пнд, 25/08/2008 в 11:40 -0700, Zac Medico пишет: Peter Volkov wrote: It's good feature for overlays, but I think we should avoid this in portage tree as having same information in two places can be avoided in this case: it's better and not so hard to write tool which will keyword packages based on package.keywords file and new keywords could be chosen like GLEP 22 suggests. I'm not sure I understand the purpose of this tool that you mention. Are you saying that package.keywords might be a good thing to use initially and then later, if we choose (maybe we will or maybe we won't), we have the option do an automated migrations of specific profiles to separate keywords like those in GLEP 22? Yes. And by initially I meant overlays outside Gentoo tree and then this tool could be useful during merge with portage tree. The question of whether or not we should implement package.keywords for the sake of private profiles should be considered separately from the question of whether or not we choose a policy to allow the use of package.keywords in one or more of our official gentoo profiles. Ok, then my answer is yes. With best regards, -- Peter.
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
В Вск, 17/08/2008 в 17:24 -0700, Zac Medico пишет: At least a few people have expressed a desire to have support for a package.keywords file in the profiles [1] as a means to add or subtract any number values to or from the KEYWORDS that apply to a given ebuild. It's good feature for overlays, but I think we should avoid this in portage tree as having same information in two places can be avoided in this case: it's better and not so hard to write tool which will keyword packages based on package.keywords file and new keywords could be chosen like GLEP 22 suggests. Or do we really want to start using profiles to force toolchain (e.g. gcc versions) like bugs.gentoo.org/show_bug.cgi?id=55321#c3 comment suggests? If so than maybe it's better to move keywording information from ebuilds to profiles and than may be there is better solution instead of having one package.keywords file? -- Peter.
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: В Вск, 17/08/2008 в 17:24 -0700, Zac Medico пишет: At least a few people have expressed a desire to have support for a package.keywords file in the profiles [1] as a means to add or subtract any number values to or from the KEYWORDS that apply to a given ebuild. It's good feature for overlays, but I think we should avoid this in portage tree as having same information in two places can be avoided in this case: it's better and not so hard to write tool which will keyword packages based on package.keywords file and new keywords could be chosen like GLEP 22 suggests. I'm not sure I understand the purpose of this tool that you mention. Are you saying that package.keywords might be a good thing to use initially and then later, if we choose (maybe we will or maybe we won't), we have the option do an automated migrations of specific profiles to separate keywords like those in GLEP 22? Or do we really want to start using profiles to force toolchain (e.g. gcc versions) like bugs.gentoo.org/show_bug.cgi?id=55321#c3 comment suggests? If so than maybe it's better to move keywording information from ebuilds to profiles and than may be there is better solution instead of having one package.keywords file? Obviously there are an infinite number of possible approaches. The main reason I brought this up was that a user had expressed a desire to have package.keywords for use in private profiles (not the official gentoo ones). The question of whether or not we should implement package.keywords for the sake of private profiles should be considered separately from the question of whether or not we choose a policy to allow the use of package.keywords in one or more of our official gentoo profiles. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiy/KUACgkQ/ejvha5XGaNF1QCgzhcQB8lnIDfB3YCC1RAnzhZI BcIAn1NBYmt4svIslKhSNCu9WK4pChpt =YEN2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
Zac Medico wrote: Does package.keywords seem like a good solution for the types of problems it's meant to solve? Would anybody like to discuss any alternative approaches? I think it's a good and easy solution to the problem(s) solar described in #55321. But as Marius [1] said this can become quite confusing very quickly, therefore we would need to limit it's usage to uclibc/hardened/$special sub-profiles imho. Otherwise it gets more of a pain in the ass. Tobias [1] http://bugs.gentoo.org/show_bug.cgi?id=55321#c11 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] [RFC] Add support for package.keywords in profiles?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, At least a few people have expressed a desire to have support for a package.keywords file in the profiles [1] as a means to add or subtract any number values to or from the KEYWORDS that apply to a given ebuild. This would allow a specific profile to alter which packages are visible to consumers of a given keyword. This is useful for profiles that differ from other profiles in some significant way despite sharing the same values for stable and unstable keywords. For example, embedded profiles which use uclibc instead of glibc. An alternative solution for some cases might be to introduce additional keywords values, such as those suggested in GLEP 22 [2]. However, the package.keywords approach may provide greater simplicity and flexibility which would allow it to serve as a solution for a larger number of use cases. For example, the uclibc profiles would not have to maintain separate keywords for every single package. Since older versions of portage will simply ignore package.keywords files that may exist in a given profile, care should be taken not to use package.keywords in older profiles that are known to be used by older versions of portage. Does package.keywords seem like a good solution for the types of problems it's meant to solve? Would anybody like to discuss any alternative approaches? [1] http://bugs.gentoo.org/show_bug.cgi?id=55321 [2] http://www.gentoo.org/proj/en/glep/glep-0022.html - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiowSgACgkQ/ejvha5XGaPb7wCcCldP1W7KBC+h5Klbvo9ccAc8 NiMAn3pnk17jbEKQ5AZnJjKHNTTE4OP9 =0jTA -END PGP SIGNATURE-
