Ticket #954 (closed enhancement: wontfix)

Opened 9 years ago

Last modified 8 years ago

Support for package.keywords in profile

Reported by: trchen Owned by:
Priority: Sometime Milestone:
Component: repositories/e Version: scm
Keywords: Cc:
Blocked By: Blocking:
Distribution: Other

Description

Support for per-profile package.keywords. Affects chromium-overlay, which is currently the only repository that makes use of it.

NOTE: the semantic of per-profile package.keywords IS DIFFERENT from /etc/portage/package.keywords or keywords.conf.

PORTAGE(5) package.keywords

Per-profile KEYWORDS. Useful for cases in which the effective KEYWORDS of a given package should vary depending on which profile the user has selected.

Attachments

paludis-package-keywords.diff Download (12.1 KB) - added by trchen 9 years ago.
preliminary patch used by chromium.org developer

Change History

Changed 9 years ago by trchen

preliminary patch used by chromium.org developer

comment:1 Changed 9 years ago by trchen

I just attached the patch, which might need some polish to meet paludis's quality standard since I'm not a professional contemporary c++ writer (yet).

comment:2 Changed 9 years ago by ciaranm

Mmm. package.keywords isn't in PMS, and I don't think we should be supporting it without that.

I'm also not really sure that I get the point of the feature. KEYWORDS are set in ebuilds, not profiles. Profiles have profile masks to play with instead. Why not just keyword things directly?

Having said that, your patch is pretty good, and won't require much more work if package.keywords gets adopted into the specification. Please use git format-patch to produce patches in the future though, so authorship gets handled automatically for us when committing.

comment:3 Changed 9 years ago by trchen

Thanks for the pointer. I didn't know that Gentoo have such a nicely-written EAPI specification.

How about that we have per-profile package.keywords support, and controlled by a eapi.conf variable so we have a chromium specific eapi that enables package.keywords?

However I personally agree with you that it doesn't make much sense to have per-profile keywords. The only hypothetical situation I can think of is that some package, say sys-apps/upstart, is very distribution-specific. It would break the system when installed in Gentoo, but should be considered as stable in Ebuild-Ubuntu(hypothetical). Well, similar functionality can be implemented using profile package.mask/unmask, so I don't really see a "need" for package.keywords either.

comment:4 Changed 9 years ago by ciaranm

If you're after a Chromium OS specific EAPI or set of EAPIs, that's certainly doable. It would require considerable input from you on what exactly you need, though, along with careful consideration of whether or not Portage support has to be kept.

As for distribution-specific, that's only an issue if you're trying to do things like use Gentoo repositories on Ubuntu. I doubt that that can sensibly be done for any non-Gentoo distribution that isn't extremely close to Gentoo.

comment:5 Changed 8 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to wontfix

So long as this is an unspecified extension, we can't support it.

Note: See TracTickets for help on using tickets.