Rewording of Review Guidelines
by Thorsten Leemhuis
Hi All!
can someone from the PC please reword
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
slightly? We had this earlier today here in #fedora-extras:
ndim> '"The primary Reviewer can be any current package owner, unless
the Contributor is a first timer."; What does that mean? I can only make
official reviews after I maintain two packages?'
Maybe something like
"The primary Reviewer can be any current package owner. Only packages
that are from first time contributors need to be reviewed from sponsors."
would be better.
Cu
thl
17 years, 7 months
pkgconfig(.pc) guildeline update proposal
by Rex Dieter
Ville asked for a clarification... here's what I propose:
# () explanations may be omitted in final draft. opinions?
MUST: Packages containing pkgconfig(.pc) files MUST Requires: pkgconfig
(for directory ownership and usability).
SHOULD: The placement of pkgconfig(.pc) files depends on their usecase,
and this is usually for development purposes, so SHOULD be placed in a
-devel pkg. (A reasonable exception is that the main pkg itself is a
devel tool not installed in a user runtime, e.g. gcc or gdb.)
-- Rex
17 years, 7 months
cmake best practices
by Orion Poplawski
It appears that more and more projects are moving to cmake, especially
with KDE4 making the jump. Two packages of mine (plplot and kdesvn) are
also making the switch. I also happen to be the current packager for
cmake itself (because I package paraview which uses it), though I expect
it will have to get moved to core relatively soon.
It seems like it is time to start collecting cmake best practices for
generating Fedora RPMS using cmake, and perhaps even creating a %cmake
rpm macro that is analagous to the %configure macro.
Here's what I have so far (note that cmake generally does out of tree
builds):
%build
mkdir fedora
cd fedora
export CFLAGS="$RPM_OPT_FLAGS"
export CXXFLAGS="$RPM_OPT_FLAGS"
cmake .. \
-DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON
make VERBOSE=1 %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
cd fedora
make install DESTDIR=$RPM_BUILD_ROOT
I'm also running into trouble getting kdesvn to install into /usr/lib64
on x86_64. This might just be a matter of educating upstream users on
the proper cmake commands for this (once I figure that out myself...).
Currently there is lots of hard coding of "lib" into install paths.
Now, where to put this in the wiki?
--
Orion Poplawski
System Administrator 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
17 years, 7 months
[Fwd: devel packages with only one .pc file]
by Jesse Keating
Forwarding this here too.
-------- Forwarded Message --------
From: Alexander Larsson <alexl(a)redhat.com>
Reply-To: List for Fedora Package Maintainers
<fedora-maintainers(a)redhat.com>
To: List for Fedora Package Maintainers <fedora-maintainers(a)redhat.com>
Subject: devel packages with only one .pc file
Date: Mon, 04 Sep 2006 15:11:26 +0200
I've recently got several bugs against package involving basically
splitting out only one pkg-config file into a -devel package, because
the packaging guidelines says so. I've done this for a couple of
packages, but its starting to get very ridicolous.
The one-file -devel package is totally useless, all it leads to is:
* Existance of -devel package means we bloat the 64bit distro with the
32bit version of the main package too.
* Developers, script or packages fail because they want to use the .pc
file but the -devel package is not installed.
* The package metadata (like changelog) stored twice in the rpm
database.
I can't really think of any advantages. What exactly is the reasoning
behind this rule?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's an ungodly neurotic stage actor on a search for his missing sister. She's
a time-travelling foul-mouthed femme fatale trying to make a difference in a
man's world. They fight crime!
--
Fedora-maintainers mailing list
Fedora-maintainers(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Jesse Keating
Release Engineer: Fedora
17 years, 7 months
python: mixing sitearch and sitelib (was: python noarch vs arch)
by Axel Thimm
OK, here is the original quoting. A user has both arch specific and
non-arch specific parts of a package and needs to decide which parts
to place under sitelib and which under sitearch.
Jesse's (wrong) answer is that if one needs to get into sitearch it
pulls the rest into there, too. It's not about files with the same
name under sitearch and sitelib as Jesse later explained, it's about a
package like python-elementtree and friends that has some parts that
are arch specific and some parts that are not. And there is no need to
move everything to sitearch contrary to Jesse's statement.
Everything clear as mud? Removing too much in quoting generates this
kind of confusion.
On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote:
> On Sat, 2006-09-02 at 16:40 +0200, Sander Hoentjen wrote:
> > On Sat, 2006-09-02 at 16:34 +0200, Sander Hoentjen wrote:
> > > I am working on packaging cohoba, this is a python gui client/mission
> > > control for telepathy. It has one small .c file, so I have a few
> > > questions:
> > > - because of the .c file the package has to by arch-specific i guess. Is
> > > there a strong preference to package as noarch? (the c part is used for
> > > changing the name for killall, so to put it as noarch i can just leave
> > > that part out (not being able to killall cohoba), or add a dependency on
> > > python-ctypes and add a small patch to cohoba to use ctypes to do it
> > > instead)
>
> If it can use all pure python, that would be best for the upstream
> project. Why reinvent the wheel?
>
> > i didn't want to send yet, so i'll continue:
> > - should i just not care about arch vs noarch and package as arch
> > specific, then where must i place the modules, all in python_sitelib and
> > only osutils (the c one) in python_sitearch?
> >
> > thanks for any pointers
> >
>
> Due to the way that python works, if any part of a python's module is
> arch specific (sitearch), the entire thing has to go into sitearch.
> Python will not import part from sitearch and part from sitelib. So
> it'd all have to go in sitearch.
>
--
Axel.Thimm at ATrpms.net
17 years, 7 months
python: mixing sitearch and sitelib (was: python noarch vs arch)
by Axel Thimm
Moving the discussion to fedora-packaging as if even memebers of the
packaging committee are confused and gove wrong advice, then this is
something that should be discussed and placed into the packaging
guidelines.
On Sat, Sep 02, 2006 at 11:09:22AM -0400, Jesse Keating wrote:
> On Sat, 2006-09-02 at 17:08 +0200, Axel Thimm wrote:
> > On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote:
> > > Due to the way that python works, if any part of a python's
> > > module is arch specific (sitearch), the entire thing has to go
> > > into sitearch. Python will not import part from sitearch and
> > > part from sitelib. So it'd all have to go in sitearch.
> >
> > That's wrong.
>
> Oh? Care to expand upon this?
>
> If you have a module, importable module that is, has an __init.py__ and
> all that, if you shove part of it in sitearch and part of it in sitelib,
> it won't work. Is this statement wrong? If so, please do explain.
You mean just the way python-elementtree (and thus yum) works exactly
that way since FC3?
Yes, that statement is wrong, just log onto a multilib system and
check ownership of parts of sitelib. For example on FC5/x86_64:
# rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm\n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64
aqbanking-1.8.1beta-3.1.x86_64.rpm
audit-libs-python-1.1.5-1.x86_64.rpm
avahi-tools-0.6.10-1.FC5.x86_64.rpm
python-elementtree-1.2.6-4.2.1.x86_64.rpm
wireshark-0.99.2-fc5.2.x86_64.rpm
--
Axel.Thimm at ATrpms.net
17 years, 7 months
