On 10/07/2013 12:09 AM, Axel Dörfler wrote:
On 10/06/2013 04:39 PM, Ingo Weinhold wrote:The various git components only use relative paths to refer to each other (or probably, rather to the core components), so git can be installed anywhere. While this is nice, breaking git up into different packages means they have to be installed in the same installation location or otherwise won't find the files they depend on.But, in the case of git, is that really a problem? Why should it be in system in the first place? It sounds pretty optional to me, at least.
Git was just an example of a software where this kind of dependency is not obvious to see. Pretty much any software which we split into different packages may have such a dependency. ATM this is true for all devel packages, since they use a relative symlink. This should be relatively easy to change, though I'm not so sure about the *-config scripts, pkgconfig and libtool files they contain.
But even if you have another software in mind that uses this method, and where it makes sense to break it up into pieces, and which happens to be installed in system: if it requires common-badbadsoftware or system-badbadsoftware instead of badbadsoftware, where is the problem assuming common-badbadsoftware somehow manages to hide/override system-badbadsoftware?
I read this paragraph a few times, but I'm afraid I still don't understand the question.
That point of view certainly makes sense, although I wouldn't introduce too many compromises because of it (like getting rid of find_directory(), or adopting a more Unix like directory scheme to ease porting efforts).
Sure. Regarding find_directory(), as we know now, it isn't a particularly good API. It failed with both the introduction of the non-packaged hierarchies and the removal of /boot/common.
CU, Ingo
