How important is %{_libdir} to arch-specific but non-multilib packages
by Toshio Kuratomi
In discussing the new Java Guidelines, we've run into the question of
whether arch-sepcific but non-multilib packages need to use %{_libdir} for
files or if they can be placed in %{_prefix}/lib/ on all arches. Although
this is a question brought to the fore by java, it also has bearing on other
situations. For instance, this fesco ticket:
https://fedorahosted.org/fesco/ticket/969
could also be affected by this question. (as noted by rdieter here:
https://fedorahosted.org/fpc/ticket/158#comment:3
)
Although we could grant a special case exception just for java, I think that
would be unfair. Making this decision on the more generic level and
applying it to java, systemd, and other packages makes more sense to me.
So what are thoughts on allowing both 32bit and 64bit binaries into
%{_prefix}/lib if those binaries are not part of a package that will be
%multilib'd?
-Tosio
10 years, 6 months
should packages be changed to use libexec?
by Matthew Miller
The Squeak VM package has several possible interpretters -- for example, a
an experimental JIT version, and a version which handles 64-bit images (a
separate issue from the arch of the system they're running on). There's also
a helper binary used solely to determine the bit-size format of an image.
Right now, these are all in %{libdir}/squeak/ with the plugins. A script
installed as /usr/bin/squeak has the logic which calls them. And in the
current test package, it's failing because the script doesn't understand
about /usr/lib64
If this stuff were packaged in the upstream to use /usr/libexec/squeak/,
then this would fit with the Fedora packaging guidelines and the /usr/bin
script wouldn't have to be tricky.
It's not, though. In this case, is it better to package the binaries into
/usr/libexec/squeak, or is it better to patch the bin script to know about
lib64? And in that case, is it better to patch the script for the right path
at rpm build time, or use runtime detection logic?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10 years, 7 months
Re: [Fedora-packaging] [Bug 874105] New: Review Request: qpid-proton - Proton is a high performance, lightweight messaging library
by Darryl L. Pierce
On Wed, Nov 07, 2012 at 02:01:30PM +0000, bugzilla(a)redhat.com wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=874105
>
> Bug ID: 874105
> QA Contact: extras-qa(a)fedoraproject.org
> Severity: unspecified
> Version: rawhide
> Priority: unspecified
> CC: notting(a)redhat.com,
> package-review(a)lists.fedoraproject.org
> Assignee: nobody(a)fedoraproject.org
> Summary: Review Request: qpid-proton - Proton is a high
> performance, lightweight messaging library
> Regression: ---
> Story Points: ---
> Classification: Fedora
> OS: Unspecified
> Reporter: dpierce(a)redhat.com
> Type: Bug
> Documentation: ---
> Hardware: Unspecified
> Mount Type: ---
> Status: NEW
> Component: Package Review
> Product: Fedora
>
> Spec URL: http://mcpierce.fedorapeople.org/rpms/qpid-proton.spec
> SRPM URL: http://mcpierce.fedorapeople.org/rpms/qpid-proton-0.2-1.fc17.src.rpm
> Description: Proton is a high performance, lightweight messaging library. It
> can be used in the widest range of messaging applications including brokers,
> client libraries, routers, bridges, proxies, and more. Proton is based on the
> AMQP 1.0 messaging standard. Using Proton it is trivial to integrate with the
> AMQP 1.0 ecosystem from any platform, environment, or language.
> Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4662498
> Fedora Account System Username: mcpierce
I'm willing to swap reviews to get this package through the process.
--
Darryl L. Pierce <mcpierce(a)gmail.com>
http://mcpierce.multiply.com/
"What do you care what people think, Mr. Feynman?"
10 years, 7 months
SPEC for multiple python versions
by Jakov Sosic
Hi.
First of all I don't know if this is the right list to ask this question
- because I'm packaging primarily for CentOS/RHEL 5/6, and not Fedora...
so if it's not please direct me to the right list.
And now to my main question. I want to write SPEC file for python
module, that should build on multiple versions of python and both CentOS
5 and 6.
I need two defines - pyver and pybasever. If I hardcode them in my spec
file -> I cannot override them from rpmbuild command line, so what's the
right approach for this problem?
I'm trying to write spec file for following combinations:
CentOS/RHEL 5 + native python (2.4)
CentOS/RHEL 5 + python26 (from EPEL)
CentOS/RHEL 6 + native python (2.6)
CentOS/RHEL 6 + python27 (my own RPM's)
and maybe some other combination too.
So far I've got this on top of my spec file:
%if ! 0%{?pybasever:1}
%define pybasever 2.6
%endif
%define __python /usr/bin/python%{pybasever}
%define pyver %(%{__python} -c "import sys ; print
sys.version[:3].replace('.','')")
If I build package with just:
rpmbuild -ba my.spec'
then python 2.6 i used, and If I specify:
rpmbuild -ba my.spec --define 'pybasever 2.x'
then python 2.x is used.
Is this by any means OK?
10 years, 7 months
is /etc/cron.*/* config file?
by Miroslav Suchý
Lets have this rpmlint error:
hylafax+.x86_64: E: executable-marked-as-config-file /etc/cron.daily/hylafax
My question is: Is /etc/cron.*/* files config file or not?
We have both precedence in Fedora. E.g package cups do not mark
/etc/cron.daily/cups as config file, but package tmpwatch mark
/etc/cron.daily/tmpwatch as config file.
--
Miroslav Suchy
Red Hat Systems Management Engineering
10 years, 7 months
