On 26 Sep, 12:48, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: >
[Quoting me...] > > However, the argument that a dependency manager cannot deal with > > different system packages is a weak one: apt and Smart have shown that > > dependency management can be decoupled from package management. > > Do you care to elaborate on how apt has shown that? I use it every day (or > at least often), but I have to admit I never delved to deeply into them - > to me it appears that apt is a retrieval-solution, not so much a dependency > management system. The dependencies are declared in the debs themselves, > used by dpkg-* - aren't they? Sure, apt does solve them, but how so > decoupled from the underlying .deps? Perhaps I was thinking more about the whole apt vs. apt-rpm situation, since apt-rpm supposedly works with RPMs, albeit in a different distribution of the software. > Regarding smart: what I read here > > """ > Smart is not meant as an universal wrapper around different package formats. > It does support RPM, DEB and Slackware packages on a single system, but > won't permit relationships among different package managers. While > cross-packaging system dependencies could be enabled easily, the packaging > policies simply do not exist today. > This is not at all different from what you can already do. In fact, Debian > has been shipping the RPM package manager for a few years now. "Possible" > does not equal "good idea", and everybody should stick to their native > package format. > """ > > in the FAQ doesn't make me think that it's just a matter of unwillingness > from the setuptools-people but instead an intrinsic property of > dependency-handling that makes cross-package-management-management (or > meta-management) hard. I think the argument is that you use your own system's package format, but smart is supposed to resolve the dependencies expressed in the packages itself. There are also universal package formats, but I think these usually leave some people disappointed, partly because you then have to consider all the different dependency representations and the inevitable integration with genuine system packages. I guess this is why dependency issues were left underspecified in the PEP. > Apart from the technical intricacies of .deb/.rpm and their respective > tools, on thing sure makes this an argument: THEY evolve as they like, and > it sure puts a lot of additional burden to the setuptools-guys to keep > track with that. I think most of the evolution has been in the surrounding tools, although stuff like the new Debian Python policy could be complicating factors. But I don't think the dependency stuff has changed that much over the years. [...] > >> For example - what if there is no debian package that provides module XY > >> in the required version? Do you rather install it into the global > >> site-packages, or do you rather keep it private to the program requiring > >> it? I'd say the latter is better in mostly all circumstances, as it will > >> not disrupt the workings of other programs/modules. [http://www.boddie.org.uk/paul/userinstall.html] > Certainly a nice solution to a real problem that might be handy for me at > some time. Yet I fail to see how that relates to the above question: if the > OS package repository fails to meet a certain version requirement, how do > you deal with that - installation local to the product you're actually > interested in installing, or in a more public way that possibly interferes > with other software? My response here was mostly addressing the "global site-packages" issue since that's usually a big reason for people abandoning the system package/dependency management. If you can't find a new-enough system package, you have to either choose a local "from source" installation (which I would regard as a temporary measure for reasons given elsewhere with respect to maintenance), or to choose to repackage the upstream code and then install it through the system package manager, which I claim can be achieved in a non-global fashion. Paul -- http://mail.python.org/mailman/listinfo/python-list
