- 1 Summary
- 2 Owner
- 3 Resources
- 4 Current status
- 5 Detailed Description
- 6 Why it would be good for Mageia to do it
- 7 Test case
- 8 Tasks
- 9 Software / Packages Dependencies
- 10 What could disrupt development of this new feature
- 11 Planning
- 12 Contingency
- 13 Release Notes
- 14 Documentation
- 15 Packager comments
Make our tools standard to help its use outside of mageia
- Name: Nicolas Lécureuil
- Email: email@example.com
- Targeted release: Mageia 7
- Last updated: 2017/09/17
- Percentage of completion: 0%
Mageia use in its tool libDrakx. This librairie could be reworked to use more CPAN libraries when possible.
Why it would be good for Mageia to do it
This can allow urpmi and drakxtools to be used on other distributions. Less custom code mean less code to maintain and less work.
Software / Packages Dependencies
urpmi drakxtools perl-URPM
What could disrupt development of this new feature
- ngompa: Isn't this the point of ManaTools? Last I checked with anaselli, most of them work fine on other distributions. In addition, Fedora is using our dnfdragora in the Fedora LXQt spin, and it is replacing Yumex-DNF entirely in Fedora 27.
- neoclust: no they are different tools. I am speaking about using less "home made" functions when some are already provided by some CPAN libraries
- anaselli: the big difference between manatools and drakx* is in libyui vs libDrakx, most of as you called home made code has been already removed and ported in ManaTools::Shared using CPAN upstream modules, that was thought just to provide a "common" part -without gui interaction- that could be even shared by manatools and drakxtools. ManaTools::Shared just contains code that does not need any x gui call, libyui part is under ManaTools::Module and ManaTools::Shared::GUI. A porting for urpmi backend was also started, but i left it there, when dnfdragora is born.