Setting CFLAGS when building python packages
by Sergio Pascual
Hello,
I was wandering if it is still needed to put set CFLAGS before compilling
python extensions, like this:
CFLAGS="%{optflags}" %{__python} setup.py build
There is nothing about it in the guidelines, altough I recall reading about
it, so perhaps it was removed from the wiki?
When comparing the compilation lines with and without setting CFLAGS, I see
lots of repeated switches but nothing clearly different.
Regards, Sergio
10 years, 9 months
Issue packaging python lib into RPM due to conflicting __init__.py
by Braddock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi folks,
I'm attempting to make an RPM of the Python package backports.lzma for
a One Laptop Per Child project using bdist_rpm.
tar xzf backports.lzma-0.0.2.tar.gz
cd backports.lzma-0.0.2
python setup.py bdist_rpm
My problem is that more than one python library wants to live under
the "backports" directory, resulting in a backports/__init__.py file
conflict on SOME platforms as each RPM attempts to create the
backports/__init__.py file in its parent directory.
For example, backports.lzma RPM conflicts with
python-backports-ssl_match_hostname
file /usr/lib/python2.7/site-packages/backports/__init__.py from
install of backports.lzma-0.0.2-1.armv7hl conflicts with file from
package python-backports-ssl_match_hostname-3.2-0.3.a3.fc18.noarch
I am uncertain how to resolve this. Is there a way for an RPM to only
create the backports/__init__.py file if it does not already exist?
There are a number of packages which would want to live under the
backports/ module.
Any advice appreciated.
Thanks,
Braddock Gaskill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJR2ZVfAAoJEHWLR/DQzlZuh/wH/R8Mj/+O4uMpNhC205TPWSx7
Ure0MAten13uALy7IVfwPS/IdtfWQhj5vdgXkv/BZLjHk26DerIZP2Wwyo/IKMw9
ZEYmouf10CF9uaDBNXmWEgXCrmgknMDqLdHYZvAuQmwrai95BUy4zTrj9PoFzKuT
h6Hx56UfpLFDeQsGaU5o2k9sR/aW356LQoQ26jNYOfUQuaWx3eJ4n64nFtfH5oPu
PDVTrWtWoCilOnLR/kerHcBWZoNxuHtOANZafyF7se0hQP4aQs1DF6Bqv6mChCOM
w/zM5wEjBb+nwUJE+/cEMJTuxMQv67rIjo+yYn8cSg06NpOUtD1Q4Azz2bmSx80=
=Gpvi
-----END PGP SIGNATURE-----
10 years, 9 months
perl(strict)
by Christopher Meng
Hi,
Do we need to split out this dep from perl in RPM spec? Someone says
it's needed and someone doesn't support this idea.
Thanks.
Yours sincerely,
Christopher Meng
Always playing in Fedora Project
http://cicku.me
10 years, 9 months
Re: [Fedora-packaging] Packaging Go libraries for Fedora
by Richard W.M. Jones
On Mon, Jul 01, 2013 at 04:14:10PM +0200, Florian Weimer wrote:
> On 07/01/2013 03:39 PM, Richard W.M. Jones wrote:
> >But for libraries that aren't bundled with the Go compiler, it looks
> >like the Go designers intended you to keep them in your home directory:
> >
> >http://golang.org/doc/code.html#Organization
>
> It's also expected that you keep around source code and recompile
> from source each time something in the dependency tree changes.
> There's no ABI stability whatsoever because internal implementation
> details (struct sizes and offsets, say) bubble up due to inlining.
Also, it'll try to recompile stuff in the %_libdir/golang directory if
it thinks it's out of date. And fail, obviously. Joy.
https://bugzilla.redhat.com/show_bug.cgi?id=973842#c23
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
10 years, 9 months
Packaging Go libraries for Fedora
by Richard W.M. Jones
(The same topic came up on this list about a month ago, with no
particular resolution).
Fedora 18+ now has a proper Go compiler, and if you get the
version in updates-testing, it's even a working Go compiler :-)
Go seems to have a "unique" approach to packaging libraries. It looks
as if everything revolves around there being a Go compiler + lots of
bundled libraries that come with that Go compiler. On Fedora this
gets installed into %_libdir/golang.
But for libraries that aren't bundled with the Go compiler, it looks
like the Go designers intended you to keep them in your home directory:
http://golang.org/doc/code.html#Organization
This is of course not so great from a packaging/security/updates
point of view.
Now as far as I can tell, we can just ignore the $GOPATH stuff, and
instead drop files into the right places in %_libdir/golang. It works
in my single, limited experiment, but I've no idea if this is the
Right Thing to do.
I think we should leave the $GOPATH environment variable alone. If
users want to install things in their home directory too, they can set
up $GOPATH and the directory structure themselves.
Thoughts on this? (especially from anyone who knows what they're
talking about, which is not necessarily me ...)
I have a small cgo library which I'd like to package for Fedora, so
this discussion is not entirely theoretical.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
10 years, 9 months
alternative packaging
by Christopher Meng
Hi all,
Can I use %postun instead of %preun to remove alternatives?
Thanks.
Yours sincerely,
Christopher Meng
Always playing in Fedora Project
http://cicku.me
10 years, 9 months
