| Summary: | Document that you shouldn't use CDEPEND (w/patch) | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Jeremy Olexa (darkside) (RETIRED) <darkside> |
| Component: | Devmanual | Assignee: | Gentoo Quality Assurance Team <qa> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | dev-portage, truedfx |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | DO_NOT_USE_CDEPEND.patch | ||
|
Description
Jeremy Olexa (darkside) (RETIRED)
2009-09-22 16:32:57 UTC
Created attachment 204936 [details]
DO_NOT_USE_CDEPEND.patch
Here is the patch.
Sorry, it is not clear what file that is patching. ebuild-writing/variables/text.xml -> http://devmanual.gentoo.org/ebuild-writing/variables/index.html If those ebuilds simply do
CDEPEND="..."
RDEPEND="${CDEPEND} ..."
DEPEND="${CDEPEND} ..."
they're not relying on any portage internals, are they? And if portage has a problem with that (which would be very surprising if 165 ebuilds are already using it), that sounds like a bug in portage to me.
CDEPEND is a reserved variable[1]. What happens when portage starts using this for something (afaik, its not used atm but it is there). So, proposed patch means that, hopefully, no *more* ebuilds start using CDEPEND and it is easier to fix the tree when something does go boom. Surely, you agree?
[1]:
%% qlist portage|xargs grep CDEPEND
/usr/bin/repoman:allvars.discard("CDEPEND")
/usr/lib64/portage/pym/portage/cache/metadata.py: 'KEYWORDS', 'INHERITED', 'IUSE', 'CDEPEND',
/usr/lib64/portage/pym/portage/cache/flat_list.py: 'KEYWORDS', 'IUSE', 'CDEPEND',
/usr/lib64/portage/pym/portage/__init__.py: 'KEYWORDS', 'INHERITED', 'IUSE', 'CDEPEND',
/usr/lib64/portage/pym/_emerge/__init__.py:_all_metadata_keys.discard("CDEPEND")
/usr/lib64/portage/bin/ebuild.sh: DESCRIPTION KEYWORDS INHERITED IUSE CDEPEND PDEPEND PROVIDE EAPI
/usr/lib64/portage/bin/ebuild.sh: unset CDEPEND
/usr/lib64/portage/bin/repoman:allvars.discard("CDEPEND")
%%
Sorry, but I don't. If CDEPEND only occurs in portage code in a way that has no effect on ebuilds, and it is not mentioned in either the already existing documentation or PMS in any way, shape or form, then ebuilds are and should be free to use it as they see fit. If portage starts giving it a special meaning in the future, it can only do so in future EAPIs anyway, so there would still not be a problem for anything already using it. And while portage giving CDEPEND a special meaning in the future is possible, it's just as possible (well, okay, slightly less, but not much less) for portage to give COMMON_DEPEND a special meaning in the future. I don't even know what CDEPEND was used for, if it was used for anything. It is not used by any recent version of portage (certainly none that anyone would be using today). So, it's safe to treat it like any other variable that has no meaning as far as portage is concerned. Any future use would certainly involve an EAPI bump, so it wouldn't matter if old ebuilds used it for other purposes. As per last comment. Thanks for the clarification all. =) I guess this CDEPEND could be removed from portage if it isn't being used :) (In reply to comment #8) > I guess this CDEPEND could be removed from portage if it isn't being used :) It currently serves as a placeholder in an ordered list if metadata cache keys. In order to remove it we'd have to replace it with another placeholder, so it's kind of pointless. The next time that we add a new cache key, we can have it replace CDEPEND. For example, we can use it for the DIGESTS value suggested here: http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml (In reply to comment #8) > I guess this CDEPEND could be removed from portage if it isn't being used :) I've replaced the CDEPEND references with UNUSED_00: http://sources.gentoo.org/viewcvs.py/portage?rev=14393&view=rev |