Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 10:46:33PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). It works fine without it only in the sense that it has to re-generate it before the program can run. Much like any compiled form of a program. + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. This property still makes it change only when the packaging system upgrades or installs software. If it only changes at that time, it still seems more appropriate for /usr/ than /var/. Well maybe, I must say I've really no hard feelings on the matter, just it looks right that way to me :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpNNVa0NjRHQ.pgp Description: PGP signature
Re: FHS location for Python libraries as locally-compiled bytecode (was: debhelper 7 and python-central)
Le mercredi 21 mai 2008 à 08:59 +1000, Ben Finney a écrit : I don't see that it leads to storing the compiled programs to live under /var/, rather than /usr/ which to my mind is more appropriate for compiled versions of programs installed by the package manager, which don't change except through explicit sysadmin action to change them. At least python-support is not the only package to do that. On my system, the following directories are generated upon package installation and will not change in other situations: /var/lib/aspell /var/lib/defoma /var/lib/dictionaries-common /var/lib/doc-base /var/lib/gconf /var/lib/iceweasel /var/lib/initramfs-tools /var/lib/libxml-sax-perl /var/lib/menu-xdg /var/lib/python-support /var/lib/scrollkeeper /var/lib/tex-common /var/lib/texmf /var/lib/usbutils /var/lib/vim /var/lib/xml-core /var/cache/app-install /var/cache/dictionaries-common /var/cache/fontconfig You can see that python-support does nothing more than following current practice. Therefore the decision of moving these files to some place in /usr should probably be made as a whole, not for a single package. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: FHS location for Python libraries as locally-compiled bytecode (was: debhelper 7 and python-central)
Josselin Mouette wrote: At least python-support is not the only package to do that. On my system, the following directories are generated upon package installation and will not change in other situations: FWIW, you forgot /var/lib/dpkg/info (And yes, I've argued before that this does not belong in /var given a strict reading of the FHS..) -- see shy jo signature.asc Description: Digital signature
Re: debhelper 7 and python-central
Pierre Habouzit wrote: This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Even if you package doesn't work with some supported Python versions? (e.g. it uses the finally clause) Emilio signature.asc Description: OpenPGP digital signature
Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 07:55:44AM +, Emilio Pozuelo Monfort wrote: Pierre Habouzit wrote: This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Even if you package doesn't work with some supported Python versions? (e.g. it uses the finally clause) Then you then don't have set XS-P-V to all, but something like = 2.4 e.g., or 2.4- in the pysupport syntax. And the result SHOULD be XB-PV: 2.4- too. So that when python 2.6 arrives, your package doesn't need to be rebuilt or whatever. IOW for arch:all packages, XB-PV should be the same as XS-PV, not the intersection betweel XS-PV and available python version at the time of the build. And again, it's what dh_pysupport does, and it's the proper thing to do. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKCg3S1qjsk.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. The .py files live in /usr/share. pysupport is supporting FHS to the letter. On the other side, pycentral puts things where they were installed, and pyc along them. That's why you find _totally_ arch indep .py files live in /usr/lib/python2.5, because they must go along with .pyc files and puting them in /usr/share where they belong would break because of .pyc files. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. pysupport is forward compatible with such a possible change in python, it would _just need_ to stop doing its symlink farm and keep byte compiled stuff in /var/lib like it does right now. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpl8FyV9yXUK.pgp Description: PGP signature
Re: debhelper 7 and python-central
Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. What makes you think 'foo.pyc' is /var material? It's compiled once when the package is installed, and shouldn't change thereafter. That isn't data that programs modify while they run, it's the binary form of the program itself. The .py files live in /usr/share. That's fine. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. Agreed, and thank you for a wonderful use of the word scabrous :-) -- \If you continue running Windows, your system may become | `\ unstable. -- Microsoft, Windows 95 BSOD message | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
Le mardi 20 mai 2008 à 00:45 +0200, Pierre Habouzit a écrit : This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Indeed, dh_pysupport puts wrong values in XB-Python-Version, so this is a bug. A very minor one, since this information is not used. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: debhelper 7 and python-central
Le lundi 19 mai 2008 à 19:22 +0100, Floris Bruynooghe a écrit : The latter approach is less fragile overall, How is that? As far as I can see both python-central and python-support maintain directories for each python version and symlink the .py files to a shared location. Just on that basis I can't see why one is better then the other. Am I missing something here? The python-central approach puts in the same directories files managed by dpkg and files managed by python-central, which means they cannot be sorted out easily, and if you run in a bug like #409390 or #480741, you’re hosed. If anything ever gets wrong with python-support, all you need to do is to run update-python-modules -f and the /var/lib/python-support hierarchy will be entirely regenerated. Because files are mixed in the same directories, python-central needs to do horrible things in the preinst scripts just to guarantee the files remain available during the upgrades. With a separate directory structure, all that is needed is to delay the cleanup (which actually resulted in reducing the code size for introducing this feature in python-support). As for the FHS argument, I don’t feel strongly for putting these files in /var/lib, it just seemed like the most obvious location as this is data that can be regenerated at any time. It can be changed very easily if there is consensus that another place is better. What I do feel strongly for, is putting them in a directory that remains separate from /usr/lib/python2.X. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. Agreed, and thank you for a wonderful use of the word scabrous :-) Heh, it's a Gallicism in fact, I mean it was a word to word translation of a quite current French expression ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbGy3AOjrUk.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 01:41:20PM +0200, Josselin Mouette wrote: Le lundi 19 mai 2008 à 19:22 +0100, Floris Bruynooghe a écrit : The latter approach is less fragile overall, How is that? As far as I can see both python-central and python-support maintain directories for each python version and symlink the .py files to a shared location. Just on that basis I can't see why one is better then the other. Am I missing something here? The python-central approach puts in the same directories files managed by dpkg and files managed by python-central, which means they cannot be sorted out easily, and if you run in a bug like #409390 or #480741, you’re hosed. If anything ever gets wrong with python-support, all you need to do is to run update-python-modules -f and the /var/lib/python-support hierarchy will be entirely regenerated. Ack, that's a good reason to keep the tool-managed directory separate from /usr/lib/pythonX.Y/. As for the FHS argument, I don’t feel strongly for putting these files in /var/lib, it just seemed like the most obvious location as this is data that can be regenerated at any time. It can be changed very easily if there is consensus that another place is better. What I do feel strongly for, is putting them in a directory that remains separate from /usr/lib/python2.X. I still do feel strongly about /var/lib, despite Pierre's good argumentation (I agree with him that a alternate shadow path directory for .pyc files would fix this). The problem is that not just the .pyc files end up on /var, but also the .py files (in symlink form). This makes it required to have /var on sys.path and that is what makes me feel really bad. I expect tools (not daemons and more exotic stuff that need runtime state) to work when /var is unmounted. Therefore I'd be much happier if python-support's managed directory was somewhere on /usr/. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). It works fine without it only in the sense that it has to re-generate it before the program can run. Much like any compiled form of a program. + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. This property still makes it change only when the packaging system upgrades or installs software. If it only changes at that time, it still seems more appropriate for /usr/ than /var/. -- \ My mother was like a sister to me, only we didn't have sex | `\ quite so often. -- Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FHS location for Python libraries as locally-compiled bytecode (was: debhelper 7 and python-central)
Josselin Mouette [EMAIL PROTECTED] writes: The python-central approach puts in the same directories files managed by dpkg and files managed by python-central, which means they cannot be sorted out easily, and if you run in a bug like #409390 or #480741, you’re hosed. If anything ever gets wrong with python-support, all you need to do is to run update-python-modules -f and the /var/lib/python-support hierarchy will be entirely regenerated. I find this a convincing argument for separating the source and compiled versions (and thank you, I hadn't thought of this). I don't see that it leads to storing the compiled programs to live under /var/, rather than /usr/ which to my mind is more appropriate for compiled versions of programs installed by the package manager, which don't change except through explicit sysadmin action to change them. As for the FHS argument, I don’t feel strongly for putting these files in /var/lib, it just seemed like the most obvious location as this is data that can be regenerated at any time. It can be changed very easily if there is consensus that another place is better. FHS 2.3 §4 allows for: /usr/libqual : Alternate format libraries (optional) Purpose /usr/libqual performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/libqual/sendmail and /usr/libqual/X11 are not required. [26] Python source code versus compiled Python bytecode certainly qualifies as an alternative binary format, so this seems the most applicable section of the FHS. Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate hierarchy to place locally-compiled bytecode for package-installed software? What I do feel strongly for, is putting them in a directory that remains separate from /usr/lib/python2.X. Thanks for your convincing argument, I'm now in support of this much. -- \ When I was little, my grandfather used to make me stand in a | `\ closet for five minutes without moving. He said it was elevator | _o__) practice. -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
On 18/05/2008, Monty Taylor wrote:
1. What are the real differences between these two?
2. Why, as a packager, would I choose one over the other?
A bit of stats:
# source-wise
$ for i in central support; do grep-dctrl -S -F Build-Depends python-$i
-sPackage /var/lib/apt/lists/*Sources | wc -l ; done
325
426
# binary-wise
$ for i in central support; do grep-dctrl -P -F Depends python-$i -sPackage
/var/lib/apt/lists/*Packages | wc -l ; done
453
593
I might be missing the Indep thingies, but you see the idea if you want
complete stats.
More seriously, you may want to compare the following:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-support
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-central
In particular, check the grave and serious keywords (coloured in red),
and the outstanding bugs.
You may also want to have a look at the maintainer scripts. From a quick
look, postinst's are mostly equivalent, from a complexity point of view.
prerm's are a bit more challenging:
(var/lib/dpkg/info/python-networkx.prerm)
| # Automatically added by dh_pysupport
| if which update-python-modules /dev/null 21; then
| update-python-modules -c python-networkx
| fi
| # End automatically added section
(/var/lib/dpkg/info/python-imaging.prerm)
| # Automatically added by dh_pycentral
| if [ $1 = remove ]; then
| if which python /dev/null 21 which pycentral /dev/null 21; then
| pycentral pkgremove python-imaging
| else
| flist=$(tempfile)
| slist=$(tempfile)
| dpkg -L python-imaging | tee $flist | \
| while read n; do
| case $n in
| /usr/share/pyshared/*)
| n2=${n#/usr/share/pyshared/*}
| case $n in
| *.py) echo p $n;;
| *) [ -d $n ] echo d $n2 || echo f $n2
| esac
| ;;
| *) continue
| esac
| done $slist
| if [ -s $slist ]; then
| for d in /usr/lib/python[0-9].[0-9]/-packages; do
| case $d in */python2.1/*|*/python2.2/*) continue; esac
| while read t n; do
| case $t in
| p) rm -f $d/$n $d/${n}[co];;
| d) rmdir $d/$n 2/dev/null || true;;
| *) rm -f $d/$n
| esac
| done $slist
| done
| fi
| awk '/\/usr\/share\/pyshared/ {next} /\.py$/ {print $0c\n $0o}'
$flist \
| | xargs -r rm -f 2
| rm -f $flist $slist
| fi
| fi
| # End automatically added section
So, if you want your eyes to start bleeding, have a look ath the preinst
scripts. Empty in the -support case. And in the -central one:
| # Automatically added by dh_pycentral
| if which pycentral /dev/null 21 pycentral --help 2/dev/null | grep -q
pkgprepare; then
| pycentral pkgprepare python-imaging PYEOF
| [python-package]
| format = 1
| python-version = 2.4, 2.5
| [pycentral]
| version = 0.6
| [files]
| /usr/lib/python2.5/site-packages/PIL=d
| /usr/lib/python2.5/site-packages/PIL/_imaging.so=f
| /usr/lib/python2.5/site-packages/PIL/_imagingmath.so=f
| /usr/lib/python2.5/site-packages/PIL/_imagingft.so=f
| /usr/lib/python2.4/site-packages/PIL=d
| /usr/lib/python2.4/site-packages/PIL/_imaging.so=f
| /usr/lib/python2.4/site-packages/PIL/_imagingmath.so=f
| /usr/lib/python2.4/site-packages/PIL/_imagingft.so=f
| /usr/bin/pilconvert.py=f
| /usr/bin/pilprint.py=f
| /usr/bin/pilfont.py=f
| /usr/bin/pilfile.py=f
| /usr/bin/pildriver.py=f
| /usr/share/pyshared/PIL.pth=f
| /usr/share/pyshared/PIL=d
| /usr/share/pyshared/PIL/EpsImagePlugin.py=f
| /usr/share/pyshared/PIL/ImtImagePlugin.py=f
| /usr/share/pyshared/PIL/SpiderImagePlugin.py=f
| /usr/share/pyshared/PIL/GdImageFile.py=f
| /usr/share/pyshared/PIL/McIdasImagePlugin.py=f
| /usr/share/pyshared/PIL/ImageColor.py=f
| /usr/share/pyshared/PIL/BmpImagePlugin.py=f
| /usr/share/pyshared/PIL/PaletteFile.py=f
| /usr/share/pyshared/PIL/GribStubImagePlugin.py=f
| /usr/share/pyshared/PIL/PsdImagePlugin.py=f
| /usr/share/pyshared/PIL/ImageMode.py=f
| /usr/share/pyshared/PIL/PcxImagePlugin.py=f
| /usr/share/pyshared/PIL/XpmImagePlugin.py=f
| /usr/share/pyshared/PIL/ImageMath.py=f
| /usr/share/pyshared/PIL/TarIO.py=f
| /usr/share/pyshared/PIL/BdfFontFile.py=f
| /usr/share/pyshared/PIL/ImageDraw2.py=f
| /usr/share/pyshared/PIL/PalmImagePlugin.py=f
| /usr/share/pyshared/PIL/ImageWin.py=f
| /usr/share/pyshared/PIL/CurImagePlugin.py=f
| /usr/share/pyshared/PIL/ImageFileIO.py=f
| /usr/share/pyshared/PIL/ExifTags.py=f
| /usr/share/pyshared/PIL/XVThumbImagePlugin.py=f
| /usr/share/pyshared/PIL/IcnsImagePlugin.py=f
| /usr/share/pyshared/PIL/FontFile.py=f
| /usr/share/pyshared/PIL/ImageTransform.py=f
| /usr/share/pyshared/PIL/SgiImagePlugin.py=f
| /usr/share/pyshared/PIL/PngImagePlugin.py=f
| /usr/share/pyshared/PIL/JpegImagePlugin.py=f
| /usr/share/pyshared/PIL/DcxImagePlugin.py=f
|
Re: debhelper 7 and python-central
Le dimanche 18 mai 2008 à 11:35 -0700, Monty Taylor a écrit : 1. What are the real differences between these two? Technically speaking, they use very different approaches. Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. The latter approach is less fragile overall, but for a handful of (IMHO broken) packages it requires a few changes (like a different path installation, or moving files to a different directory). 2. Why, as a packager, would I choose one over the other? As the python-support maintainer, I could recommend it because it has more features, like namespace packages (allowing to split modules coming from the same directory in non-interdependent packages), Python-Depends (allowing to express Provides: in a way that doesn’t break when the list of supported python versions changes), or triggers support (leading to faster upgrades). As the maintainer of several python-related packages, I have noticed recurrent breakage on user systems caused by bugs in python-central, and I avoid it for this precise reason. 3. Is there a valid reason to have both of them be acceptable if they both do the same job? Probably not, but I’m not in the right position to judge. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 12:49 PM, Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 18 mai 2008 à 11:35 -0700, Monty Taylor a écrit : 1. What are the real differences between these two? Technically speaking, they use very different approaches. Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. The latter approach is less fragile overall, but for a handful of (IMHO broken) packages it requires a few changes (like a different path installation, or moving files to a different directory). 2. Why, as a packager, would I choose one over the other? As the python-support maintainer, I could recommend it because it has more features, like namespace packages (allowing to split modules coming from the same directory in non-interdependent packages), Python-Depends (allowing to express Provides: in a way that doesn't break when the list of supported python versions changes), or triggers support (leading to faster upgrades). As the maintainer of several python-related packages, I have noticed recurrent breakage on user systems caused by bugs in python-central, and I avoid it for this precise reason. 3. Is there a valid reason to have both of them be acceptable if they both do the same job? Probably not, but I'm not in the right position to judge. I am glad this discussion is taking place. I'd like to add this to our FAQ, is anyone against it? Matthias Klose, as the maintainer of python-central, do you have any comments to this? I.e. if the above statements are accurate, it seems to me that python-support is now better than python-central -- do you have any plans to fix this, or what is the motivation of python-central? I know you suggested me to follow the changelog of it to know what is happening, but I am also interested in your future plans with it and especially what you don't like on python-support. So that we can find some common ground and either have two packages if there are two good approaches to the same thing that people just cannot agree on one, or just one package if the reason for two packages are just communication problems that we will fix/explain in this thread. Ondrej
Re: debhelper 7 and python-central
Hi On Mon, 19 May 2008 12:49:11 +0200 Josselin Mouette [EMAIL PROTECTED] wrote: As the python-support maintainer, I could recommend it because it has more features, like namespace packages (allowing to split modules coming from the same directory in non-interdependent packages), Python-Depends (allowing to express Provides: in a way that doesn’t break when the list of supported python versions changes), or triggers support (leading to faster upgrades). As the maintainer of several python-related packages, I have noticed recurrent breakage on user systems caused by bugs in python-central, and I avoid it for this precise reason. Sorry to jumping into this debate, but I also tried debhelper 7 and because of no current support for pycentral, it meant to switch to pysupport. I have no strong preference any of them, in fact I have no idea why I started to use pycentral over pysupport. What surprised me is different handling of XB-Python-Version field. I have XS-Python-Version: current and python-central makes XB-Python-Version: current from this, what I feel is correct (package is pure Python, no dependency on Python version) and package Depends: python, what corresponds to this. However python-support makes XB-Python-Version: 2.5 out of this while still depending on any python version. Is this bug, I'm doing something wrong or it is expected behavior? It is just strange to see disparity between dependencies and Python-Version field. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: debhelper 7 and python-central
Le lundi 19 mai 2008 à 14:39 +0200, Michal Čihař a écrit : What surprised me is different handling of XB-Python-Version field. I have XS-Python-Version: current and python-central makes XB-Python-Version: current from this, what I feel is correct (package is pure Python, no dependency on Python version) and package Depends: python, what corresponds to this. If your package is pure python and doesn’t have a dependency on a python version, you should make it XS-Python-Version: all (or simply remove the field). XB-Python-Version: current has no meaning. Either the package is architecture-independent and it must list all python versions supported by the modules, or the package is architecture-dependent and it must list all python versions for which it was built. As for XS-Python-Version: current, it is, at best, a declaration that says “This package only supports one version at once.” However I have noticed it is often different from what the package actually implements. Such things can be detected automatically at build time, and the fact that the build system is multi-python or not has no impact on the way the modules need to be treated. The fact that the semantics of “current” are broken has been discussed several times, and it is something that is still not fixed in the Python policy. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: debhelper 7 and python-central
Dne Mon, 19 May 2008 18:38:25 +0200 Josselin Mouette [EMAIL PROTECTED] napsal(a): Le lundi 19 mai 2008 à 14:39 +0200, Michal Čihař a écrit : What surprised me is different handling of XB-Python-Version field. I have XS-Python-Version: current and python-central makes XB-Python-Version: current from this, what I feel is correct (package is pure Python, no dependency on Python version) and package Depends: python, what corresponds to this. If your package is pure python and doesn’t have a dependency on a python version, you should make it XS-Python-Version: all (or simply remove the field). Well I did this at the end. So now I get XB-Python-Version: 2.4, 2.5. But I see no reason why package should not work with 2.6. I'm just a bit confused that XB-Python-Version is more strict that generated dependencies. I thought these fields should match somehow... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: debhelper 7 and python-central
Hello On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: Le dimanche 18 mai 2008 à 11:35 -0700, Monty Taylor a écrit : 1. What are the real differences between these two? Technically speaking, they use very different approaches. Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. This is actually the only reason I use python-central[0]. I'm rather convinced that python-central follows the FHS better. From the horse's mouth: /var contains variable data files [1] and: /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] The latter approach is less fragile overall, How is that? As far as I can see both python-central and python-support maintain directories for each python version and symlink the .py files to a shared location. Just on that basis I can't see why one is better then the other. Am I missing something here? Regards Floris [0] I also like the XS-Python-Version and XB-Python-Version fields but don't feel strongly about that (and don't fully understand the issues at hand there). And I've never run in any of the bugs. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 06:47:10PM +, Michal Čihař wrote: Dne Mon, 19 May 2008 18:38:25 +0200 Josselin Mouette [EMAIL PROTECTED] napsal(a): Le lundi 19 mai 2008 à 14:39 +0200, Michal Čihař a écrit : What surprised me is different handling of XB-Python-Version field. I have XS-Python-Version: current and python-central makes XB-Python-Version: current from this, what I feel is correct (package is pure Python, no dependency on Python version) and package Depends: python, what corresponds to this. If your package is pure python and doesn’t have a dependency on a python version, you should make it XS-Python-Version: all (or simply remove the field). Well I did this at the end. So now I get XB-Python-Version: 2.4, 2.5. But I see no reason why package should not work with 2.6. I'm just a bit confused that XB-Python-Version is more strict that generated dependencies. I thought these fields should match somehow... FWIW python-support doesn't have such restrictions, as it doesn't hardcodes into the binary it produces the current python versions that were available at the time of the build (which is by essence volatile information) it's forward compatible, which pycentral isn't. This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Such information must be kept only for arch:any packages, where we must remember for which python versions the binary extensions have been built. Private or public extensions have the same requirement in that regard, it's just that private extensions can _only_ be built for one python version at a time. That was probably for them that current was invented in the first place I think. Though it's useless as the dh_py* helper can figure that out by himself, and it's exactly what pysupport does. Pycentral OTOH requires a declarative list from the maintainer in XS-P-V, _AND_ the maintainer to build what he claimed to have built, which may differ, which is brittle. pysupport just looks at what has been built and computes things from that only, which is way more robust, because information exists in a single place. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8DDvws3aFF.pgp Description: PGP signature
Re: debhelper 7 and python-central
Floris Bruynooghe [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. -- \ It seems intuitively obvious to me, which means that it might | `\be wrong. -- Chris Torek | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
