Re: Linda warnings about manpages in my packages
On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote: On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote: If it's not supposed to be a public module, it shouldn't be in a public directory, and then there's no reason to provide more packages than just the application package. FWIW, this is not the common attitude in the Python community; people think it's a good idea to store application-specific modules and extensions in the site directory, even if there's no API/ABI stability. For example, I've had several requests for Quod Libet to install its entire private module hierarchy there. You'll find that several programs in Debian, such as gnome-menus, do this already. Personally I think that's very stupid, and leads to 1) a false sense of security about the stability of such APIs, and 2) a lax attitude towards API compatibility in general in Python (since so many public modules break all the time). Yes; putting libraries in public directories that aren't going to support a stable API/API for the lifetime of a release (be it Debian or python) is simply namespace pollution. It's unfortunate that every language community has to grow into an understanding of this the hard way. If Debian is going to buck the trend here (and I think it should, and thankfully does for many programs) a lot of packages are buggy. Well, I think a lot of packages are buggy is a pretty accurate assessment whether Debian adopts a blanket policy on this or not... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linda warnings about manpages in my packages
On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote: If it's not supposed to be a public module, it shouldn't be in a public directory, and then there's no reason to provide more packages than just the application package. FWIW, this is not the common attitude in the Python community; people think it's a good idea to store application-specific modules and extensions in the site directory, even if there's no API/ABI stability. For example, I've had several requests for Quod Libet to install its entire private module hierarchy there. You'll find that several programs in Debian, such as gnome-menus, do this already. Personally I think that's very stupid, and leads to 1) a false sense of security about the stability of such APIs, and 2) a lax attitude towards API compatibility in general in Python (since so many public modules break all the time). If Debian is going to buck the trend here (and I think it should, and thankfully does for many programs) a lot of packages are buggy. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Linda warnings about manpages in my packages
On 4/20/06, Marco Bertorello [EMAIL PROTECTED] wrote: Hi Folk, I've three packages: denyhosts-python2.3 denyhosts-python2.4 denyhosts-common the binaries are stored in packages -python2.X but the manpage (common to alla packages) is stored in denyhosts-common. E: denyhosts-python2.3; No manual page for binary denyhosts. The binary E: denyhosts-python2.4; No manual page for binary denyhosts. The binary What is, in your opinion, the right way to operate? Make both -py2.3 and py2.4 packages depend on -common, document this in the changelog. Can I ignore these linda warning? I guess you could. Add a linda override file for each of the -py2.x packages, install them in the corresponding packages, document and forget. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: Linda warnings about manpages in my packages
Hi, On Thu, 20 Apr 2006, Marco Bertorello wrote: denyhosts-python2.3 denyhosts-python2.4 denyhosts-common the binaries are stored in packages -python2.X but the manpage (common to alla packages) is stored in denyhosts-common. Why would you have a binary in -python2.3 *and* in -python2.4 ? And why can't you simply provide a single package an you make the choice to use either python2.3 or python2.4 ? I don't see the gain of having two versions of the same application just to work with two different python version... (it's different for Python modules because the user must be able to use the modules with the Python version of its choice) If your application works with python2.3 (default python version for the moment), then you use that and you're done. Once python2.4 is the default, you update your package to work with python 2.4 and you're done. And if you believe that the modules are useful for the end-user, then the current packaging make sense (bin and manpages in -common and modules in -python2.X). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings about manpages in my packages
On Thu, 20 Apr 2006, Steve Langasek wrote: denyhosts-python2.3/2.4 do contain a python module. If and when the Great Python Reorganization finally happens, this ought to be a single denyhosts package depending on python ( 2.3), python ( 2.5). This can already be done with python-support (provided that the code isn't specific to a python version). Since the package installs public modules, it seems to me that putting the modules and the app in a single package is the wrong solution. We have plenty of modules which are packaged only for the current version of python in Debian and it's not wrong. This wouldn't be worse. And the maintainer really needs to think if the modules are meant to be public or not ... because I see no documentation of the modules, so I wonder why we need to provide them for two python versions. However, trying to make the application package auto-switch between two different versions of python is also the wrong solution. Indeed. In the meantime, the current packages have an RC bug, #361085, about the fact that denyhosts-comon *does* include a binary that tries to support both versions of python, but without appropriate dependencies to ensure a consistent python configuration. Given the info that I've read here, if I were the maintainer I would have a single package denyhost with everything packaged for the default version. If I wanted to provide the modules for another python version I would use python-support. Check http://wiki.debian.org/DebianPythonFAQ for some info about how to use python-support. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
