On 29 April 2017 at 18:29, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > There's plenty of stuff going on in rpm.org upstream. You can look for > yourself: https://github.com/rpm-software-management/rpm Seems none is going to provide %doc and %lang() generalisation to allow mark more than current 5 classes of the files within packages like normal/regular file, %doc, %lang, %config and %ghost (%ghost is practically %config with some exact %verify rules). None is going towards provide IPS mediator functionality as well. > I've even personally contributed to it. If you feel there is missing > functionality, feel free to contribute and improve it. The upstream is > very active, with contributions from individuals from Red Hat/Fedora, > Mageia, SUSE/openSUSE, and even from BSD and Mac users! I cannot find some polite words when I'm trying to describe what I'm thinking when I'm looking on OpenSuse spec files .. but this is only my private opinion. However from the begging SuSE guys had always problems with understanding RPM as the technology (they've been using it for quite long time as dumb Slackware tgz PM replacement without significant changes on specs layer). I would not expect any significant help from other rpm based distros communities. Bottleneck is related to lack of people with enough deep/long PM exp. > As the saying goes: Talk is cheap! And this is what exactly I'm doing .. Problem is that most of the Linux folks have kind of natural Solaris "allergy' thinking about it as legacy or dead OS. Yep guys .. you are all wrong :-P Solaris was, is and will be because Linux cannot bring to the desks of the many engineers technologies which are available on Solaris OOTB .. ONLY. Truth is that on *many* areas Solaris still is more than decade ahead of Linux and all this progress happen after Solaris 10 (so don't tell me about your exp using Sol < 10 :) ) Just one example of last catch which is still in kind of embryonic stage on Linux: https://www.theregister.co.uk/2016/11/01/linux_in_2016_catches_up_to_solaris_from_2004/ Solaris userland changes are almost the same frequent as Fedora (https://java.net/projects/solaris-userland/sources/gate/history?) It is plenty of thing which could be adapted on Linux from Solaris. What I'm trying to do now is more or less prevent reinvention all those things second time :) > IPS may have some awesome capabilities, so why not add them to RPM? No > one has ever said we can't add best of breed features to RPM. This is not about awesomeness. Some features are *needed*. Full stop. Without those features more and more people will be bouncing own head over bigger and bigger packages fragmentation with growing web of dependencies and simple wasting time and not doing more important things. Really try to have look closer on IPS https://java.net/projects/ips/sources/pkg-gate/show/ If you will look closer you may see that size of the python code in which IPS is written is few times smaller with all additional python modules compare to whole RPM code (source or binary). Its is so simple because it bases on things which are still unimaginable in LinuxWorld(tm) like doing upgrade on separated clones of all affected FS not optionally like in ostree but unconditionally (ZFS on Solaris is now only available FS which is supported to install distro resources). Other set of features is related to 100% fixed set of actions (more or less analogues of %filetrigger* in rpm). For many RPM developer and packagers it will be total surprise that it was possible to build fully functional packaging layer *without* possibility to add even single customisation of the scriptlets fired during pre/post install/uninstall!!! Despite exactly those differences which affects semantics of install/upgrade/remove/roll back IPS code provides as well all necessary code of the services with package repository server, proxy, maintenance tools. All with encryption/authentication etc. Effectively IPS repo server it is set of resources served over http/https using apache + few small bits in apache settings .. no rocket science. As IPS started from much wider set of problems which even now not bothers typical Linux packager they (Sun developers) been able to make few significant code layer generalisations/simplifications. Parts which could be used on %doc/%lang generalisation (like IPS facets), and variants management (mediators) and few other gems like consolidations should be quite easy to extract from IPS and adapt on top RPM. However mediators will require to change paradigm of the package as archive to something which exist as the object in repository (IPS allows export from repo package as archive but they are used only on transferring resources between repos). With this step already done switching to the space in which packages provides multiarch resources sharing as much as it is only possible will be formality. IMO first step on this path could be stop using rpm and switch to use dnf only (few weeks ago I've showed here that now it is doable) and hide those necessary changes in dnf gut. IMO rpm as it is now is more or less unmanageable and only way to avoid its code deeper changes is provide end user abstraction layer anchored on dnf. Problem of the dnf is that it is still not matured software and it evolved already to the level of over complication in command syntax (look on IPS "pkg" command syntax). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
