Summary: | =dev-java/ant-antlr-1.7.1 and others: EAPI change without version change | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Robert W. <slrn_robert> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | ciaran.mccreesh, java, software, tb |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240304 | ||
Attachments: | only use live ebuild's *DEPEND if the EAPI is supported |
Description
Robert W.
2008-09-29 07:30:33 UTC
Well, only ~arch ebuilds were changed this way. The general rule is that only stable arch and ~arch as a whole are supported, and combinations of something ~arch unmasked while e.g. portage stays stable is not officially supported. So yes, you should do "upgrading portage to a version, which supports EAPI 2". But I'll leave this open for Betelgeuse's opinion as it was him updating the ebuilds to new EAPI. I thought Portage would be using the info from vdb for installed stuff nowadays if the main tree things weren't usable but I guess I was wrong. Any way why doesn't Portage give the normal update notice in this situation? *** Bug 239032 has been marked as a duplicate of this bug. *** (In reply to comment #2) > I thought Portage would be using the info from vdb for installed stuff nowadays > if the main tree things weren't usable but I guess I was wrong. Any way why > doesn't Portage give the normal update notice in this situation? As workaround for odd dependencies in the tree, portage uses *DEPEND from ebuilds in the live tree instead of from the vdb. Historically, this has served to solve problems such as those caused by modification of the QT3VERSIONS variable in q3.eclass. When this hanging this variable is changed to accommodate a new qt version, it renders the *DEPEND outdated for all installed packages whose dependencies were generated from an earlier QT3VERSIONS setting. If all the packages exhibiting problems such as this have been fixed, then eventually we can remove the live *DEPEND workaround from portage. However, we shouldn't do it until we are sure that the most stable users no longer have such problematic dependencies in their installed packages. In svn r11600 I've changed the behavior so that it will always use the vdb metadata in cases when the live ebuild's EAPI is unsupported. *** Bug 239066 has been marked as a duplicate of this bug. *** (In reply to comment #4) > If all the packages exhibiting problems such as this have been fixed, then > eventually we can remove the live *DEPEND workaround from portage. However, we > shouldn't do it until we are sure that the most stable users no longer have > such problematic dependencies in their installed packages. Please let's discuss this on the -dev ML before you implement this. I personally quite dislike the idea of revbumping on each dependency version restriction, for example... (In reply to comment #7) > Please let's discuss this on the -dev ML before you implement this. I > personally quite dislike the idea of revbumping on each dependency version > restriction, for example... What's stopping you from writing correct deps to begin with now? (In reply to comment #7) > Please let's discuss this on the -dev ML before you implement this. I > personally quite dislike the idea of revbumping on each dependency version > restriction, for example... We might consider implementing a metadata update protocol, similar to the one that's currently used for package moves and slot moves. This will give us an avenue to correct metadata problems without needing to reinstall the whole package. Created attachment 167471 [details, diff]
only use live ebuild's *DEPEND if the EAPI is supported
If this patch is saved as /tmp/eapi_supported.patch then it can be applied as follows:
patch /usr/lib/portage/bin/emerge /tmp/eapi_supported.patch
This is fixed in portage-2.1.4.5. |