Summary: | Merge (live-)ebuilds amarok-utils and amarok | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andreas Stangl <mail> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WORKSFORME | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andreas Stangl
2009-11-08 22:59:33 UTC
It might be nice to have the amarok-9999 ebuild have USE flags that control the building of the utils, player, or both. That would help prevent this type of problem. We could merge them back together, but in that case what would be the interest of having split packages for the releases? I can live with both options (split and monolithic amarok), but I think we should make an option and be consistent for releases and live versions. I think the devs should help us decide this. I don't know any package that needs amarok-utils as a seperate package. Jeff Mitchell said in the kde bugtracker (https://bugs.kde.org/show_bug.cgi?id=213143#c18), they requested the splitting because amarok-utils does not depend on X and can therefore be run on an headless machine, but I don't exactly know why it would make sense to run the collection scanner without amarok... I agree that it might be a bad idea just to merge the live-ebuild and have split ebuilds in the main tree, because it makes things inconsistent. Adding a use flag to the overlay and the main tree does also not really make sense because amarok-utils will automatically be rebuilt in the main tree when it is updated. I personally vote for the merge of both packages in both trees, what do you think? Well, the amarok devs are not willing to merge the packages, gentoo devs should not add different handling for live ebuilds and common ebuilds so I am closing this. Always rebuilding both packages by hand "works for me" (TM). Beside this I'm going to give the official ebuilds a try again, I hope they are more stable that they were in the past... |