> > This is only sortof true. You can install rpms into a local directory > without root privileges with a commandline switch. But rpm/deb are > optimized for system administrators so the documentation on doing this > is not well done. There can also be code issues with doing things this > way but those issues can affect bundled apps as well. And finally, since > rpm's primary use is installing systems, the toolset around it builds > systems. So it's a lot easier to build a private root filesystem than > it is to cherrypick a single package. It should be possible to create a > tool that merges a system rpmdb and a user's local rpmdb using the > existing API but I'm not aware of any applications built to do that yet.
Building private root kind of defeat the purpose :) Deploying linux packages in a reliable way without requiring admin privileges is an "interesting" experience. The tools just don't support this well - or there exists some magical tools that I've never seen mention of. > I won't argue for setuptools' implementation of multi-version. It > sucks. But multi-version can be done well. Sonames in C libraries are > a simple system that does this better. I would say simplistic instead of simple :) what works for C won't necessarily work for python - and even in C, library versioning is not used that often except for a few core libraries. Library versioning works in C because C model is very simple. It already breaks for C++. More high-level languages like C# already have a more complicated scheme (GAC) - and my impression is that it did not work that well. The SxS for dll on recent windows to handle multiple version is a nightmare too in my (limited) experience. >> > I'm confused -- if it will happen whatever tools are available, how does > "good source control" solve the issue? I'm saying that this is not an > issue that can be solved by having good source control... it's a social > issue that has to be solved by people learning to avoid bad practices. I meant that whatever technology is available, bundling everything will always be easier. And sometimes, given the time/resource constraints, that's even the only realistic option. I could tell you many stories about wasted hours related to some fortran libraries which were hopelessly broken (missing symbols) on most distributions, or ABI conflicts - for which bundling sometimes is the only path to keep its sanity (short of giving up support for the platform). When you need to solve the problem now because you want to demo things tomorrow, not in 6 months, that's the only solution. It is not always bad practice. IMHO, one should focus on making it easier to avoid bundling everything - robust and simple dependency scheme, adapting distutils installation scheme to the various OS conventions, be it FHS, windows, etc... But we can't and shouldn't prevent it totally, and tools are already there to help minimizing the problems of bundling. For multiple system-wide libraries, I have yet to encounter anything which makes it somewhat reliable - it has only caused problems for me, and not solved any single problem. cheers, David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
