| Summary: | Portage fails to construct runtime dependencies for packages under kde/applications | ||
|---|---|---|---|
| Product: | kde-windows | Reporter: | Jasem Mutlaq <mutlaqja> |
| Component: | buildsystem | Assignee: | KDE-Windows <kde-windows> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | albertvaka |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | portage.py patch | ||
Created attachment 99154 [details]
portage.py patch
Small patch to fix the problem
Please submit patches to Phabricator. See: https://community.kde.org/Get_Involved/development#Submitting_your_first_patch. |
While trying to use 'emerge --package kstars', the emerge process never finds the required runtime dependencies for KStars and install them as needed to the archive directory. After a bit of investigation, the problem turns out to be getDependencies( category, package, runtimeOnly = False ): function in portage.py. For applications that fall under portage/kde/applications/*, the function returns the subpackage as "applications" but that fails when it tries to call _getSubinfo("kde", "applications) as it cannot find the applications.py file since it doesn't exist. Attached is a small patch that fixes this problem. However, a bigger issue is that tree layout itself. There are many applications (kdevelop, ktorrent, k3b) that fall under portage's "extragear" while others fall under "kde/applications". What's the reason for this? It seems inconsistent. Reproducible: Always Steps to Reproduce: 1. emerge --package kstars 2. 3. Actual Results: no runtime dependencies installed Expected Results: runtime dependencies installed