Revised Emacs add-on guidelines
by Jonathan Underwood
Dear All,
We've recently added some macro definitions under
/etc/rpm/macros.[x]emacs to simplify add on packaging for (X)Emacs.
The main point being that we no longer use the pkg-config way of
finding directory locations etc at add-on package build time, which
removes all the boiler plate stufff that was being added to every add
on package. A new draft of the guidelines is here:
https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised
Comments welcome!
Best wishes,
Jonathan
13 years, 5 months
disttag doesn't work
by Martial Paupe
hello,
I'm building packages and I want to use disttag as referred at this page.
https://fedoraproject.org/wiki/Packaging:DistTag
as a result the package is named as is
packagename-1.0.0-1.noarch.rpm instead of
packagename-1.0.0-1el5.noarch.rpm
here the head of my specfile.
Name: packagename
Version: 1.0.0
Release: 1%{?dist}
Summary: some text
Group: application
License: Propriatory
URL: http://somewhere.domain.com
Source0: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Conflicts: libgcj
%description
more text in these area
%package binary
Summary: packagename binary and library
Group: System
%if 0%{?rhel} >= 4 || 0%{?rhel}
Requires: jre
else
Requires: java-1.6.0-openjdk
Obsoletes: jre
%endif
Obsoletes: packagename-stack
......
......
......
......
What I do wrong? Thanks for your help
13 years, 6 months
Re: How to patch against strip?
by Tareq Al Jurf
>
> Richard, I think he's just asking for help about where to look for
> avoid stripping his binaries _before_ RPM strips them and creates the
> debuginfo stuff.
>
> He's probably getting empty debuginfo packages at the moment and wants
> to fix the build.
>
> Tareq, is this the situation you're in?
>
Omg!!
That's that's exactly my problem :)
--
Tareq Al Jurf
Fedora Ambassador
Riyadh, Saudi Arabia
taljurf(a)fedoraproject.org
13 years, 6 months
Naming guidelines: Parents & children
by Christoph Wickert
Hi,
I have packaged gtkhash [1]. The latest version comes with a nautilus
extension that I'd like to package separately so gtkhash can be
installed without GNOME/nautilus.
I wonder what the proper name for the nautilus extension package is.
gtkhash-nautilus-extension? gtkhash-nautilus? nautilus-gtkhash?
The naming guidelines read [2]:
"If a new package is considered an "addon" package that enhances or adds
a new functionality to an existing Fedora package without being useful
on its own, its name should reflect this fact."
The extension is cannot be used without ether nautilus or gtkhash, so
this wont help us to make a decision. From the "enhancement" point of
view I'd say it's nautilus that gets enhanced, so the proper name would
be nautilus-gtkhash. On the other hand gtkhash-nautilus(-extension)
makes it easier to find the package in bugzilla.
So the question is: What is the "parent"? The source package or the one
that gets enhanced?
This affects other nautilus packages as well. Currently we have:
Package (Source package)
* brasero-nautilus (brasero)
* gnome-mplayer-nautilus (gnome-mplayer from "that other repo")
* nautilus-actions (nautilus-actions)
* nautilus-beesu-manager (beesu)
* nautilus-bzr (bzr)
* nautilus-extensions (nautilus)
* nautilus-image-converter (no subpackage)
* nautilus-open-terminal (nautilus-open-terminal)
* nautilus-phatch (phatch)
* nautilus-python (nautilus-python)
* nautilus-search-tool (nautilus-search-tool)
* nautilus-sendto (nautilus-sendto)
* nautilus-sound-converter (nautilus-sound-converter)
* tortoisehg-nautilus (tortoisehg)
* totem-nautilus (totem)
I think we should tighten the naming guidelines a little to make our
package names more consistent, especially gnome-panel applets:
Package (Upstream source name)
* autobuild-applet (autobuild-applet)
* contact-lookup-applet (contact-lookup-applet)
* deskbar-applet (deskbar-applet)
* file-browser-applet (file-browser-applet)
* gdm-user-switch-applet (gdm)
* gnome-applet-alarm-clock (alarmclock)
* gnome-applet-bubblemon (bubblemon)
* gnome-applet-cpufire (cpufire_applet)
* gnome-applet-globalmenu (subpackage of gnome-globalmenu)
* gnome-applet-grandr (grandr_applet)
* gnome-applet-jalali-calendar (jalali-calendar)
* gnome-applet-music (music-applet)
* gnome-applet-netspeed (netspeed_applet)
* gnome-applets
* gnome-applet-sensors (sensors-applet)
* gnome-applet-sshmenu (sshmenu)
* gnome-applet-timer (timerapplet)
* gnome-applet-window-picker (window-picker-applet)
* hamster-applet (subpackage of hamster)
* lock-keys-applet (lock-keys-applet)
* resapplet (not an applet but a tray icon)
* zapplet (not an applet but a tray icon)
Proposal:
1. Leave tray icons as is. They can be used in all desktops.
2. Rename all gnome-panel applets to gnome-applet-*
3. Packages that don't match the upstream name get a "Provides:
<upstream-name> = %{version}" so they can be installed more easy
Instead of 2. we could prefix all applets with "gnome-" and leave the
upstream names intact. This is what we currently have in Xfce, upsteam
has a consistent naming of their plugins, all are named xfce4-*-plugin.
What do you think is best?
Regards,
Christoph
[1] https://bugzilla.redhat.com/show_bug.cgi?id=540328
[2]
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_....
13 years, 6 months
code vs. content
by Ralf Corsepius
Hi,
There is a package (london pictures) under review[1], which I consider
to be a corner case wrt. "Code vs. content"[2].
The problem I have with this package providing a precedence of how to
circumvent Fedora's regulations/guidelines etc. to use Fedora as means
to distribute "mere content".
In other words, I fear this package is a precedence to opens a can of
worms for content packages.
What to do about this package and about this issue in general?
My gut feeling is, Fedora should refine their "code vs. content" rules,
otherwise we will soon Fedora being filled up with arbitrary
"photo/sound/video collections" disguised as "backgrounds", "sound
fonts", etc.
Ralf
[1] https://bugzilla.redhat.com/show_bug.cgi?id=538557
[2] https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
13 years, 6 months
Proposal: support multiple Python minor versions
by David Malcolm
Proposal: support multiple Python minor version, as one instance of a
generalized way of supporting variant stacks.
Currently we support a single version of Python; we pick a specific
minor-release of Python (currently "2.6", in fact 2.6.4 in rawhide), and
all modules are assumed to be for that "2.MINOR" version of Python.
We plan to extend this further in Fedora 13, with the idea that there's
additionally a specific minor-release of Python 3 (currently "3.1", in
fact 3.1.1), and all python3-foo rpms are assumed to be for that
"3.MINOR" version of Python [1]
Some people want more: they want additional minor versions: for example,
when we want to upgrade "python" to mean "python 2.7", we will rebuild
all our RPMs for 2.7, but some users may have code written to 2.6 that
they don't want to bother porting.
This makes more sense in an EPEL context: in EPEL5 we have the system
python as "2.4", but many people want a "2.6" stack, others want "2.3",
2.5", "3.1", etc etc.
There are ways of doing this within the current Fedora/EPEL packaging
framework, but it would lead to an explosion of specfiles and CVS
directories. I dislike this: I think of specfiles as human-readable
source code for driving a reproducable build; I hate having many
almost-identical copies of a source file.
I had an idea for how this could be done whilst minimizing "specfile
explosion"; it allows for the generation of parallel families of RPMs
from one specfile, moving the complexity from the individual packager
into the build system, and onto release-engineering (sorry Jesse!) - and
eating up more disk space, build time, etc.
Caveat: I haven't looked into the details of whether Koji, package CVS,
and Makfile.common can actually cope with some of the ideas here, and
I've not tested the specifics of the rpm macros; the proposal is
independent of but compatible with the Python3 feature (I think).
PROPOSAL:
- Introduce the following new packaging macros:
- "pyprefix":
- defined as "python" for the system build of python
- defined as "pythonMN" for a build of python-M.N e.g. "python26"
for "python-2.6"
- for use in the names of packages
- "pysuffix":
- defined as the empty string for the system build of python
- defined as "-M.N" for builds of python-M.N e.g "-32" for
"python-3.2"
- for use in /usr/bin when giving alternative versions of tools e.g.
"/usr/bin/pydoc-3.2" to be the python-3.2 version of "pydoc"
- Within python-foo module specfiles and the python module packaging
guidelines:
- Add default definitions of the macros:
%{!?pyprefix: %global pyprefix python}
%{!?pysuffix: %global pysuffix}
- Change:
Name: python-foo
to:
Name: %{pyprefix}-foo
and similarly for all dependencies, so that e.g.:
BuildRequires: python-devel python-setuptools
becomes:
BuildRequires: %{pyprefix}-devel %{pyprefix}-setuptools
- In %install, move scripts if necessary (to allow
parallel-installability), adding:
for script in foo bar baz ; do
mv %{buildroot}/usr/bin/$script mv
%{buildroot}/usr/bin/$script-%{pysuffix}
done
This gives us a single specfile, which can be used with different
definitions of these macros to give multiple builds, leading to multiple
SRPMs (the package changes name for the alternative builds).
Where do these macros gets expanded out?
Say in Koji's "dist-f14" we have python = python2.7 and python3 =
python3.2, and we want to support alternative python stacks.
Then for the dist-f14 build tags, introduce multiple new tags:
dist-f14-altbuild-python23
dist-f14-altbuild-python24
dist-f14-altbuild-python25
dist-f14-altbuild-python26
dist-f14-altbuild-python30
dist-f14-altbuild-python31
Each of these "altbuild" tags inherit from the main dist-f14 build tag,
adding a single RPM: "rpm-altbuild-macros-pythonMN-0.1-1.fc14" e.g.
"rpm-altbuild-macros-python26-0.1-1.fc14" which contains a single file:
/etc/rpm/altbuild-python26.macros
(changing the version as appropriate), defining the macros:
%global pyprefix python26
%global pysuffix -2.6
%global __python /usr/bin/python2.6
(need to ensure this last one actually gets used; need to move the
define from rpm to python-devel)
These Koji tags are in addition to the regular one ("dist-f14"), in
which "python" and "python3" have their default meanings.
All of these tags would deposit their built packages into dist-f14
Similarly, for EPEL5, extend "dist-5E-epel-testing-candidate",
introducing multiple child tags:
dist-5E-epel-testing-candidate-altbuild-python23
dist-5E-epel-testing-candidate-altbuild-python25
dist-5E-epel-testing-candidate-altbuild-python26
dist-5E-epel-testing-candidate-altbuild-python27
dist-5E-epel-testing-candidate-altbuild-python30
dist-5E-epel-testing-candidate-altbuild-python31
all of which would deposit their built packages into
dist-5E-epel-testing-candidate
For packaging CVS, add a new, optional file to a dist CVS subdirectory,
"build-variability". So for package "python-foo",
"python-foo/EL-5/build-variability" might contain these lines:
dist-5E-epel-testing-candidate-altbuild-python23
dist-5E-epel-testing-candidate # 2.4 is the default in EPEL5
dist-5E-epel-testing-candidate-altbuild-python25
dist-5E-epel-testing-candidate-altbuild-python26
dist-5E-epel-testing-candidate-altbuild-python27
dist-5E-epel-testing-candidate-altbuild-python30
dist-5E-epel-testing-candidate-altbuild-python31
If "build-variability" is present, it would change the meaning of "make
build": instead of triggering a job that does a single build into
"dist-5E-epel-testing-candidate", it would create a job that builds into
all of the build tags listed in the file. If any of these builds fail,
the whole build fails, and no RPMs reach he destination tag.
If a particular module only works with some minor-releases (perhaps it
doesn't work with python 3 yet, or needs python>=2.4 etc), then the file
would be edited appropriately.
I have no great love for "build-variability" as a name.
Caveat: I'm handwaving here; I haven't looked into the details of what
it would take on the Koji side and to Makefile.common
We'd be going from two dimensions of variability:
- build architecture (i386, x86_64 etc; currently expressed internally
in Koji)
- OS release (devel, F12, EPEL5 etc)
where we have a CVS directory per OS-release (one dimension)
up to three dimensions of variability:
- build architecture (i386, x86_64 etc)
- OS release (devel, F12, EPEL5 etc)
- Python minor release (2.3, 2.4, 2.5, 2.6, etc)
whilst keeping just one CVS directory per OS-release; the package
maintainer only has to edit a single specfile, and can attempt to ensure
that it builds across all minor-releases he/she cares about;
release-engineering would have a fair bit of extra complexity to deal
with though.
It may be necessary to add extra macros to the altbuild macro files so
that specfiles can somehow easily conditionalize the build for altbuild
variants matching some criteria (e.g. on altbuild for 2.6 and above,
need this extra Patch3")
I've tried to structure this so it can be reused for other language
runtimes where we might want to support multiple versions; perhaps the
Perl SIG would want a similar family of "altbuild" macros (I'm not a
perl person so maybe I'm missing something here).
The proposal only exposes a single extra dimension of variability;
higher dimensionality seems to lead to combinatorial explosion (e.g
sqlalchemy versions).
It also assumes (perhaps overoptimistically) than these other language
runtimes are independent, so that we never have collisions where e.g.
something wants to consume both multiple python stacks and multiple perl
stacks. This assumption fails for the case of e.g. multiple parallel
versions of say postgres or httpd, etc where you might also want
multiple versions of python, and multiple mod_pythons M * N
combinatorial explosion [2]
Thoughts? Total insanity?
Dave
[1] https://fedoraproject.org/wiki/Features/Python3F13
[2] so for e.g. python-psycopg2 you could unroll a 2-dimensional
variability table into the file in dist-CVS, and into Koji tags,
expressing all combinations of the postgres libs and of the python minor
version; similarly for shipping multiple httpd versions versus python
versions for mod_python. This many-dimensional approach quickly gets
too complex to deal with, I think.
13 years, 6 months
How to patch against strip?
by Tareq Al Jurf
I'm building a package
Probably the package’s ‘make install’ function invokes ‘strip’ on the
binaries it produces. How do i patch the Makefile to not do that.
Thanks in Advance
--
Tareq Al Jurf
Fedora Ambassador
Riyadh, Saudi Arabia
taljurf(a)fedoraproject.org
13 years, 6 months
Obsoletes in renamed rubygem a blocker?
by Jeroen van Meeuwen
Hi there,
I've had rubygem-net-ldap packaged and deployed throughout my company,
e.g. on all development workstations and on all dev/test/beta/prod servers.
My company is letting me package this ruby gem for Fedora as well, along
with a bunch of other ruby gems. During the review[1], M. Tasaka
suggested the name should have been rubygem-ruby-net-ldap instead, and
so I added an Obsoletes header for rubygem-net-ldap.
This is now a blocker for M. Tasaka to approve the package, but if and
when I remove it, and the new package is in Fedora I have to manually
update all of approximately 40-50 development workstations and Fedora
servers. I just need that Obsoletes header to be in the RPM, and that
RPM with that header to be in the updates repository once.
More details are in the review request[1], and I would appreciate your
opinion on this Obsoletes header becoming a blocker.
Kind regards,
Jeroen van Meeuwen
-kanarip
[1] https://bugzilla.redhat.com/show_bug.cgi?id=532309
13 years, 6 months
