Le lundi 28 novembre 2005 à 11:27 -0600, Ian Bicking a écrit : > That's okay; I'll just tell my users to use it when Debian packages are > not available (which is the case for the majority of Python libraries, > and probably always will be unless libraries are automatically > packaged). easy_install provides a much better and safer experience > than downloading tarballs and using the normal "setup.py install" > routine; it is an improvement on the status quo. The other option would > be to allow people to easily create debs, in the same way they can > easily create RPMs right now; but I get the strong impression you don't > think that's a good idea. Creating debs easily is a good idea if done correctly, but only for packages that will eventually enter the archive. It's a very bad idea to encourage people to build their own versions of Debian packages. It would lead to a horrible cluttering of package sources, and to the disappearance of any coherent versioning scheme. However, if a semi-automated way to produce Debian source packages is available, like it is for CPAN modules, it can only be a good thing, as it will be used to make loads of packages that can enter the archive. And there's no reason why all these python modules couldn't enter the archive. > > Stable releases are not meant for developers like you, but there are > > developers who want a stable development platform, even if it has some > > bugs. No bug fixing also means no regressions. The fact you don't > > understand those people's needs - and forget them when designing your > > tools - doesn't make all stable releases "counterproductive". > > I'm speaking in terms of the open source ecosystem -- gaining > contributors is far more valuable than gaining users. So from my > perspective -- which isn't out of line from Debian's, I think -- cutting > off feedback is damaging. More users also mean more contributors. Stable releases mean more users, especially corporate users who aren't likely to contribute from the beginning, but who may become contributors later. And I strongly disagree with your statement we are cutting off feedback. You seem to forget your software isn't the only one out there; we are providing a centralized way to get feedback, redistributing it when necessary. This makes things much easier for users when they have only one way to give feedback. > > Developers who want a bleeding edge development platform should be using > > Debian testing or unstable, where the new versions become available as > > soon as possible. > > I don't think those really provide the same experience. If you are > really serious about the bleeding edge, you should be using a checkout > from the upstream repository. Which, incidentally, setuptools and > easy_install handle nicely. But again, I say that from the perspective > of someone who wants to gain contributors, not just users. What if you want bleeding edge, yet tested software? You're going to use the latest release of the software, not the CVS snapshot. When you're developing a project based on TurboGears, I'm sure you don't want to use the CVS tree. You're going to use the features as soon as they are available in the release. And releases are available in Debian unstable. > New versions don't overwrite old versions. I believe that if you have a > library in /usr/lib, and install a new version to /usr/local/lib, that > the new version won't ever be accessible until you specifically > pkg_resources.require() it (or implicitly require it due to > dependencies). *However*, to make that work nicely an easy_install'ed > package should see metadata about Debian installed packages; otherwise > duplicate versions of libraries have to be installed, because it's not > reasonable to discover at runtime what Debian packages are installed (if > only because the Debian package database is much too slow). Though if > you really wanted, setuptools/easy_install could be patched to read the > debian package database on installation, maybe even writing a .egg-info > directory then (putting it in /usr/local/lib, but it can refer back to a > library that was installed in /usr/lib). That mostly depends on the > enthusiasm of the setuptools packager. You're mixing things again, and again, and again. Debian dependencies should NOT be mixed with lower-level dependencies. A clean way of doing things would be a shlibs-like mechanism. However, it would require dependencies to be written only in metadata files. As I understand it, they can also be asked directly in python code, in which case there's no reliable way to tell a package needs another package. > Anyway, in spite of all the disagreement, I think we actually have > reached a sort of conclusion... > > For the packages in question (ultimately leading to packaging > TurboGears) there's only one current Debian package of consequence: > ElementTree. I think it's fine to remove that package in particular > from the egg dependencies. So the timescale for changes to Debian > aren't that much of an issue because these are new packages. Most of > the libraries are developed with setuptools upstream... I think all of > them, in fact (setuptools itself, TurboGears, Kid, SQLObject, > FormEncode, probably nose as well). That can be done in the unstable package. However, you're still going to get complaints from sarge users because your software won't see the stable ElementTree package. The same goes for RHEL4 users. Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=