Red Hat Bugzilla – Bug 192310
Review Request: PySyck
Last modified: 2007-11-30 17:11:33 EST
Spec URL: http://michaeldehaan.net/software/RPMS/PySyck.spec SRPM URL: http://michaeldehaan.net/software/RPMS/PySyck-0.61.2-1.src.rpm Description: YAML is a data serialization format designed for human readability and interaction with scripting languages. Syck is an extension for reading and writing YAML in scripting languages. Syck provides bindings to the Python programming language, but they are somewhat limited and leak memory. PySyck is aimed to update the current Python bindings for Syck. The new bindings provide a wrapper for the Syck emitter and give access to YAML representation graphs. PySyck may be used for various tasks, in particular, as a replacement of the module pickle """ History -- syck-python in FC Extras is a package that provides syck bindings that do not have serialization support (they are broken) and there is a bugzilla on this. Previously I suggested PyYaml for inclusion as an alternate to syck-python, though PyYaml does not do Yaml 1.0. This package (PySyck) supports Yaml 1.0, which represents most of what YAML is "in the field" today. This would provide a working YAML parser/serializer for Python that also can read YAML as written by Ruby's stock modules and the C syck implementation, for instance.
Missing BuildRequires python-devel Remove Vendor tag Using Prefix for relocatable packages is strongly discouraged. http://fedoraproject.org/wiki/Packaging/Guidelines#RelocatablePackages I recommend using python template from fedora-rpmdevtools package.
You should also add dist tag to release in SPEC file. For that check http://fedoraproject.org/wiki/DistTag
Ping. Please comment in a week if you are still interested in packaging this. I notice that a blog has replaced the spec and srpm URLs.
My mail filter must have missed the earlier two replies -- my apologies. Following the traffic on yaml-core for PyYAML (which is picking up considerably), I don't think packaging this is neccessary. I personally don't like the way YaML is growing in complexity, but it appears there is much more active development there in the 1.1 stuff after all -- and given that, I don't think we really want a bunch of users piling on a dead-end codebase. The application that needed this as a prereq has moved on to other serializing options.