| Summary: |
Portage fails to construct runtime dependencies for packages under kde/applications |
| Product: |
[Unmaintained] kde-windows
|
Reporter: |
Jasem Mutlaq <mutlaqja> |
| Component: |
buildsystem | Assignee: |
KDE-Windows <windows-bugs-null> |
| Status: |
RESOLVED
FIXED
|
|
|
| Severity: |
normal
|
CC: |
albertvaka
|
| Priority: |
NOR
|
|
|
| Version First Reported In: |
unspecified | |
|
| Target Milestone: |
--- | |
|
| Platform: |
Microsoft Windows | |
|
| OS: |
Microsoft Windows | |
|
|
Latest Commit:
|
|
Version Fixed/Implemented In:
|
|
|---|
|
Sentry Crash Report:
|
|
| |
|---|
| Attachments: |
portage.py 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