On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote: > am I the only one who thinks that this way leads to madness? > > Version conflicts are bad enough.
First, version conflicts have their roots in the support for versions of libraries in softwares. This is the best place to fix that when possible. When it comes to ebuilds maintainers, version conflicts are about all about DECLARATIONS. If software A need Y-v1..12, we should have a way for the maintainers to declare that A relies on Y-v1..12 and let the dependency softwares to the hard job and admin/users handle them the way they want. Today, this is badly managed with implicit expectations everywhere. Also, there are ways to overcome version conflicts. Slots are one of them. > No multiply that with a bunch of > overlays, all having their own libXY with just some tiny, tiny > differences, and another bunch of overlays who want libXY from certain > others.... That's a reason why I said that overlays are a poor kind of pointers. For overlay maintainers today, if the main portage tree does not offer what they expect, the only option they have is to rewrite their own "static" dependency tree with their own ebuilds. That sucks. Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. -- Nicolas Sebrecht
