[Bug 165686] Review Request: Syck - YAML for Ruby, Python, PHP and OCaml

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: Syck - YAML for Ruby, Python, PHP and OCaml


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165686





------- Additional Comments From toshio at tiki-lounge.com  2005-08-24 18:33 EST -------
Note: Re Comment #4
Ruby on FC4:
[badger at katahdin syck-0.55-3]$ rpm -ql ruby-libs |grep syck
/usr/lib64/ruby/1.8/x86_64-linux/syck.so
/usr/lib64/ruby/1.8/yaml/syck.rb

Good:
- Naming matches upstream and folows the naming guidelines
- spec file named appropriately
- License is BSD
- License included in package
- Spec is in American English
- Spec is comprehensible
- Source matches upstream
- No locale so no %find_lang
- No Prefix

Needswork:
- License in spec should read BSD rather than GPL
- Remove BR: /usr/bin/install (it comes from coreutils)
- Remove BR: python (python-devel pulls it in)
- For the python subpackage we need::
  Requires: python-abi = %(%{__python} -c "import sys; print sys.version[:3]")
- Leave out OCaml from the Summary as there's no OCaml extension.  Also leave
out Syck from the summary as it's redundant.
- Leave out README.BYTECODE as you're not building that extension (or build
  and include it.  Reading the docs seems to impy it's an extension to the
  syck library that will preparse a YAML document into bytecode that can then
  be re-loaded by the library.  Could be reading that wrong, though.)
- Shared libraries need to be left executable or they won't be stripped for
  debuginfo packages.
- Static libraries and headers go in a -devel package.  See below about creating
a dynamic library for the extensions:
- When making the library and loadable mdules, needs to supply RPM_OPT_FLAGS
  to the build process.
- We can't BR: php-devel = ... [something that expands to the php-config
  command] because the comand isn't present until after the BR is fulfilled.
  If there's a specific version that's needed, use that, otherwise just use
  BR: php-devel.
- Doesn't build the python or php extensions due to not having a libsyc compiled
with -fPIC.  (ie: we have a libsyck.a which was build without -fPIC.  We need a
  libsyck.so that was built with -fPIC.)
  This problem has to go upstream to be fixed because with shared libraries
comes stricter versioning requirements.  However, hacking together some libtool
based scripts is not incredibly hard.  As long as upstream is amenable we could
do the actual work here.
- The php doesn't build due to the build process not finding either the syck
  library or header.  Something like this should work:
  CFLAGS="$RPM_OPT_FLAGS -I../../lib" %configure --with-syck=../../

Minor:
- Since the %post/%postun scripts contain just /sbin/ldconfig it would be
  possible to use %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig.  My
  understanding is this format allows rpm to do some optimizations (not
  loading a shell to invoke ldconfig and running ldconfig only once when a
  group of libraries are installed as one transaction.)
- There's a slew of 64bit related warnings.  However, I don't see anything
that's obviously causing problems (such as the failure of the check on x86_64.)

Summary
=======
If you want to work with upstream about the failure of the regression test and
whether libtool-based dynamic libraries are desirable I can get started on
creating some libtool infrastructure.

TODO
====
Since I couldn't get a completed package, these things have not been
checked:
- rpmlint
- Check against complete PackagingGuidelines
- Recheck BR in mock


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.