> It seems that "not wanting to support software" is somehow connected > to "not providing the software for download" in people's minds
Indeed. As a package author, I find that highly plausible. If the software is no longer available anymore, people will stop using it, so they won't bother me with support requests. > this > is exactly the reason why the maintainer of the package that triggered > this discussion for me removed these older versions. And as a result > he probably got more support issues than if if he'd left them around. > :) That's only temporary. When the dust settles, people with either move to a newer version, or use something else altogether. > You can also see this as a historical record or version control issue. > Just because version 0.7 is in a version control system somewhere > doesn't mean that the developers are going to support this version. In free software, you have to support stuff when people contact you. So removal is the easiest way to reduce the amount of time you have to spend for support. > But in this case, I don't see developers argue there that this > historical version should therefore be removed. That's because the users that cause support effort don't check out the software from the repository - those that do check out old versions don't contact you for support. > With dependencies, my project in version control (or in released > tarball form) has a dependency on an external system. I could instead > check all dependencies into my version control system, or I could > depend on an external system with more guarantees. For example, you could depend on the source control system of the software you are depending on. > That's the feedback > I'm getting: either use a system with more guarantees such as a Debian > release, or check everything into my own version control system. But > this isn't always feasible. I can understand the problem. I'm just telling you that the solution you propose is an unacceptable interference with the freedom of the package authors (and this comes from somebody who thinks that a rating system is *not* an unacceptable interference with that freedom). > * debian might not have my dependencies available yet, or a different version, I won't give advice to you, just saying what I do: use the version in Debian. If it doesn't work, adjust your code until it does. If something isn't in Debian, I try to work without the package, possibly rewriting some of the functionality. If the amount of rewriting would be too large, I make an exception and install from PyPI. When doing so, I try to find a version whose dependencies can again be satisfied from PyPI. > * I want to hack on the stable and development version of my project > without having to install a virtual linux for each to make sure the > debian dependencies are right I try to depend only on released version of software, both for stable and development versions, and preferably on the same version of the dependency. So I can use a single Python installation. Regards, Martin _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
