public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [RFC] Add support for package.keywords in profiles?
@ 2008-08-18  0:24 Zac Medico
  2008-08-18 22:37 ` Tobias Scherbaum
  2008-08-25 18:03 ` Peter Volkov
  0 siblings, 2 replies; 6+ messages in thread
From: Zac Medico @ 2008-08-18  0:24 UTC (permalink / raw
  To: Gentoo Dev

-----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-----



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
  2008-08-18  0:24 [gentoo-dev] [RFC] Add support for package.keywords in profiles? Zac Medico
@ 2008-08-18 22:37 ` Tobias Scherbaum
  2008-08-25 18:03 ` Peter Volkov
  1 sibling, 0 replies; 6+ messages in thread
From: Tobias Scherbaum @ 2008-08-18 22:37 UTC (permalink / raw
  To: gentoo-dev

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

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

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
  2008-08-18  0:24 [gentoo-dev] [RFC] Add support for package.keywords in profiles? Zac Medico
  2008-08-18 22:37 ` Tobias Scherbaum
@ 2008-08-25 18:03 ` Peter Volkov
  2008-08-25 18:40   ` Zac Medico
  1 sibling, 1 reply; 6+ messages in thread
From: Peter Volkov @ 2008-08-25 18:03 UTC (permalink / raw
  To: gentoo-dev

В Вск, 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.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
  2008-08-25 18:03 ` Peter Volkov
@ 2008-08-25 18:40   ` Zac Medico
  2008-09-01 14:43     ` Peter Volkov
  2008-09-02 15:18     ` Wolfram Schlich
  0 siblings, 2 replies; 6+ messages in thread
From: Zac Medico @ 2008-08-25 18:40 UTC (permalink / raw
  To: gentoo-dev

-----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-----



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
  2008-08-25 18:40   ` Zac Medico
@ 2008-09-01 14:43     ` Peter Volkov
  2008-09-02 15:18     ` Wolfram Schlich
  1 sibling, 0 replies; 6+ messages in thread
From: Peter Volkov @ 2008-09-01 14:43 UTC (permalink / raw
  To: gentoo-dev

В Пнд, 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.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
  2008-08-25 18:40   ` Zac Medico
  2008-09-01 14:43     ` Peter Volkov
@ 2008-09-02 15:18     ` Wolfram Schlich
  1 sibling, 0 replies; 6+ messages in thread
From: Wolfram Schlich @ 2008-09-02 15:18 UTC (permalink / raw
  To: gentoo-dev

* Zac Medico <zmedico@gentoo.org> [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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-09-02 15:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-18  0:24 [gentoo-dev] [RFC] Add support for package.keywords in profiles? Zac Medico
2008-08-18 22:37 ` Tobias Scherbaum
2008-08-25 18:03 ` Peter Volkov
2008-08-25 18:40   ` Zac Medico
2008-09-01 14:43     ` Peter Volkov
2008-09-02 15:18     ` Wolfram Schlich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox