[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