On 28 April 2017 at 21:32, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > You do keep saying that it's easy. What I'm saying is that it's easy to > say things are easy, but... from experience, usually they are not. If > it *is* that easy, why not make a proof of concept? In any case, taking > them to the RPM project upstream is probably more fruitful than what > amounts to effectively nagging people who are attempting to make > improvements to _use_ within the existing functionality of the > software. You see it is only one big hole in you logic .. IPS exist!!! As long as you still going to refuse that IPS existence I must agree with you that it is really hard .. however I'm not going to share your pain because I'm using it on daily bases. Just control question: did you ever try *one time* to have look on IPS in meantime? If not this conversation does not make any sense because it is like trying to explain you taste of some dish you never been eating and probably never going to try. FYI: no one working on RPM is interested extending its functionality (try to have look on what they are working on rpm 5.x on http://rpm5.org/). In other words you may expect that Project Modules with its new needs will have NULL support from RPM developers. Ergo: without changes to import some IPS functionalities like mediators which are able to check dependencies on switching variants this project is already sentenced to FAIL. Developers working on this project don't know about this or still refuses some basic facts and it may take them even few years until they will agree that without deeper changes in PM layer it will be not possible to reach goals of this project. Just my personal opinion: because IMO adding to RPM functionalities will require at least 2-3 full time developers for +1 year and it will be not possible to rewrite it easily (RPM have <censored> over complicated code). IMO more likely will be that within next few years some Linux folks will take IPS as it is and will start packaging Linux stuff using this PM software. It will be not a first time in Linux history when Linux will be borrowing something from Solaris. What you are guys trying to do with separating more and more noarch subpackages is moving whole PM technology to pre-RPM era (+~22 years). Really .. good luck with that. More packages -> more dependencies -> higher probability that something will fail within resolving those dependencies. As long as even few years ago disk space was kind of issue today it is nothing more than minor issue (even on small embedded systems it will be less and less problem). All those noarch separation will make more and more difficult use Linux software provided by Fedora. Just one example: try to press F1 on any GNOME application and quite possible that you will see nice small dialog box that help is not available. Only small percentage of the people will start scratching own head trying to ask "why?" And maybe few will find that it is because someone decided to separate help files from *all* GNOME desktop application. Long term result: less and less people will care about those help pages its quality or translations to other languages .. Yes you can start adding missing here dependencies but easier would be just fix those issues by merge these resources because current separations adds only complexity in spec files. After such merge if someone hates to have installed any documentation it will be very good solution by just add one line in /etc/rpm/rpmrc and reinstall all packages by "rpm -qa | xargs dnf reinstall -y" (it will take 20min to maybe 2-3h depends on network bandwidth and CPU speed but recipe to do this is b*dy easy). Cases when someone is using Linux with 32/64 bits binaries already is decreasing. Investing time in more separation is already lost effort. You may ignore me or name me as an idiot/fool (as some other people in this thread not able to add any new argument) but I'm only messenger .. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
