On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: > On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht > <nicolas.s-...@laposte.net> wrote: > > Portage should support a way to expose ALL the conditions for a software > > to work and update installed libraries to match the requirements. > > This sounds nice in principle, but making it work is not trivial. > > Suppose my package works with gcc-1.2.3.4 with a list of 14 specific > patches and no others, and glibc-1.2.3.4 with another list of 14 > patches and no others. Now suppose 300 other packages have similar > requirements.
To make it simple, this is almost irrelevant IMHO. It won't happen because we are talking about patches required as dependency excluding other patches required as dependency on the same sources. IOW, we must notice that we would need multiple *installed* versions ONLY IF a dependency requirement is not met AND that this requirement is *excluding* one of the current gcc requirements. So, when they are non-compatible themselves in some way at the source level. On top of that, this would have to be an issue that has to be handled by the software devs. > Second, good luck dealing with security patches and bugfixes. You now > have 300 copies of glibc to update, and since your list of > dependencies stated that you have 14 patches and no others you now > need to update the 300 other packages to use the newer version of > glibc. > > The current Gentoo way is far more limiting, but by having a single > version of glibc with a single policy around versioning/etc packages > don't have to micromanage what they depend on. Well, I wouldn't worry about that because having 300 versions of gcc (or any other package) is not the purpose. But it is a very good thing to restart the thread from patches handling like you did since it is the basis of software updates. When it comes to building a real and flexible meta-distribution (after all, this thread is all this issue), it is nice to have the packages management tools working for you. Also, it is good to keep in mind that everybody in the chain from the software developers to the users including fork developers, package-distro maintainers, sysadmin and the final users might want to tune their systems at some point. They are all some kind of "forkers" with the current Gentoo. Starting from there, the tools should not only allow them to do what they want but also help them in that task WHITOUT forking. If it's not the case, you end up with overlays or similar technics whose come which much more damaging problems in practice. All distributions manage vanilla sources + patches (including security patches and bugfixes). We start from vanilla with compilation options. Each one is declared so they are enabled/disabled easily (use flags...). Would it be that hard to declare if the patch add/remove/change a dependency? I don't think so. Now comes the series of patches management. Would it be hard to have the tools allowing to tune the series of patches that are going to be applied? I don't think so, either. Would it be hard to have the tools allow each role to tune/configure the system for both useflags and series of patches? Neither, we know how to do that kind of things since decades. So, when there are security fixes or bugfixes we don't need anything much crazy to handle them: the management of series of patches is already supported of the tools. Today, ebuilds don't even let a chance for an admin to apply a series of patches to the vanilla/distro-maintainer sources without having to rewrite/fork the ebuild. Whatever it is critical for them. The lone option is to fork+overlay. This is a serious issue FMPOV. > If NixOS/etc have found a better solution I'm all ears, but it is hard > to tell based on the info on their website. It seems hard to me to > allow so much diversity in dependencies without basically having every > package on your system running in its own container (thus consuming a > lot more RAM), and while managing security updates in a sane way. I don't know about NixOS/etc. I'll look at that. About containers, they are usefull for solving other problems like testing, deployement or required isolation, IMO. -- Nicolas Sebrecht
