<div class="gmail_quote">On Sat, Dec 8, 2012 at 8:02 AM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> *) Not all packages built build on top of that system.  There are rpm<br><div class="im">
> packages provided by upstreams that users attempt (to greater and lesser<br>
> degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc.  There<br>
> are debs built for Ubuntu that people attempt to install onto Debian.<br>
<br>
</div>Sure.  But the reference points still exist, and there is a layer of<br>
indirection between "packager" and "developer", even in the case where<br>
the packager and developer are the same person or organization.  In<br>
the Python case, there is usually no such indirection, outside of<br>
curated systems like SciPy et al.  (Even there, most of what<br>
third-party packaging is about in the Python world is taking care of<br>
binary builds.)<br>
<br>
Again, it's islands in the ocean vs. pools on land.<br></blockquote><div><br>To strain the analogy, the main value of these fields exists on the beach: at the point where you need to impedance match between the Python community and another packaging community.<br>
<br>The ideal is to be able to get a point where you can point an automated tool at a project on PyPI and say "give me that, only packaged as RPM/deb/whatever, with appropriate distro specific metadata". Such a tool is obviously going to be distro specific, since it is going to have to do some remapping based on file names to pick up existing distro packages, but it *also* needs upstream metadata.<br>
<br>Even in a distro, a "Conflicts:" field often *does* denote runtime conflicts (e.g. over a particular network port), because, as you say, filesystem level conflicts will usually be picked up automatically. The distro philosophy is to say "OK, we simply won't let you install conflicting projects at the same time, so you won't be surprised later by a conflict that only shows up if you happen to run them both at the same time". It's designed to turn a complex, hard to debug, problem into a simple, explicit error at installation time.<br>
<br>People build complex systems (especially web apps) based on the PyPI ecosystem, and the upstream communities *can* assist in flagging potential issues in advance. If people start putting bad metadata in their projects, then that's just a bug to be dealt with like any other.<br>
<br>Cheers,<br>Nick.<br><br></div></div>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>