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

bugzilla at redhat.com bugzilla at redhat.com
Thu Aug 25 09:05:28 UTC 2005


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 oliver at linux-kernel.at  2005-08-25 05:05 EST -------
(In reply to comment #6)
> 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

Yes, yes. I just had a look into the ruby-package not the -libs.

> Needswork:
> - License in spec should read BSD rather than GPL

Done.

> - Remove BR: /usr/bin/install (it comes from coreutils)

Done.

> - Remove BR: python (python-devel pulls it in)

Done.

> - For the python subpackage we need::
>   Requires: python-abi = %(%{__python} -c "import sys; print sys.version[:3]")

See comment from Ville...

> - 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.)

Done.

> - Shared libraries need to be left executable or they won't be stripped for
>   debuginfo packages.

Guess, I catched that.

> - Static libraries and headers go in a -devel package.  See below about creating
> a dynamic library for the extensions:

Do you really think, I should create another subpackage?

> - When making the library and loadable mdules, needs to supply RPM_OPT_FLAGS
>   to the build process.

OK, I think I catched that also.

> - 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.

This copied from another php extension. This works fine, as there is the || echo
stuff...

> - 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.)

Added RPM_OPT_FLAGS and -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=../../

Added your patch.

> 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.)

You're right. Done.

[ ... ]

> 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.

Sounds fine.

> TODO
> ====
> Since I couldn't get a completed package, these things have not been
> checked:
> - rpmlint

Fixed lint warnings.

> - Check against complete PackagingGuidelines

Did that.

> - Recheck BR in mock

Doin' that right now.



Please review again.

-- 
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.




More information about the fedora-extras-list mailing list