Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 583922 - vala.eclass: vala_depend eclass function returns invalid slot when ebuild doesn't exist
Summary: vala.eclass: vala_depend eclass function returns invalid slot when ebuild doe...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks:
 
Reported: 2016-05-24 05:53 UTC by Dave Kennedy
Modified: 2019-03-14 17:24 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Kennedy 2016-05-24 05:53:16 UTC
This function is returning 0.24, which is no longer in the Portage tree. The problem appears to be on line 55:

    for ((minor_version = ${VALA_MAX_API_VERSION#*.}; minor_version >= ${VALA_MIN_API_VERSION#*.}; minor_version = minor_version - 2)); do
        if ((minor_version >= minimal_supported_minor_version)); then
            echo "0.${minor_version}"
        fi
    done
Comment 1 Mart Raudsepp gentoo-dev 2019-03-14 17:24:53 UTC
We can't avoid QA warnings like this when we support newer than we have available in main tree.
We can avoid them for old versions by updating the oldest supported when old vala is removed, and that's all clean right now. But 0.44 warning is there and will stay there until 0.44 is added. And at that point it will probably be made to warn about non-existent 0.46 instead. That's because otherwise overlays, that support development versions of vala before we have them in main tree, need this from the main tree eclass, otherwise they have to copy over all vala inheriting ebuilds verbatim to the overlay just to be able to build and test them with the newer vala.

Given that we don't warn about 0.24 versions long ago, I'm marking this bug as fixed now years late.

If someone thinks of a way to avoid the problem with newer versions, please open a new bug. But to me the solution is just getting to the point again in our manpower and backlog where we can promptly add a development vala cycle ourselves to main tree (probably p.masked) in the same push as we add support for it in vala.eclass.