define versus global !?
by Farkas Levente
hi,
sorry for cross posting but may be someone on the packaging/rpm side can
help me. i'm getting really angry about the debug packages:-)
does anybody who can tell me the real reason of why:
------------------------------------
%define __debug_install_post %{mingw_debug_install_post}
------------------------------------
works why
------------------------------------
%global __debug_install_post %{mingw_debug_install_post}
------------------------------------
not?
imho if i can know the answer to this question i can solve my only
remaining issue with generated spec file for mingw.
if why this in the spec file working:
------------------------------------
%define __debug_install_post %{mingw_debug_install_post}
------------------------------------
while this not:
test:
------------------------------------
echo "%define __debug_install_post %{mingw_debug_install_post}"
------------------------------------
and in the spec file:
------------------------------------
%global test sh /tmp/test
%{expand:%(%{test})}
------------------------------------
???
the same thing is working for all other macro except for
__debug_install_post.
thanks in advance.
regards.
--
Levente "Si vis pacem para bellum!"
11 years, 7 months
Systemd scriptlet comments
by Ville Skyttä
Some comments on systemd scriptlets at
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
1) I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts
and one does a version bump in the previous distro - the trigger in the
next one will no longer run on distro upgrades because of the
versioning. Wouldn't it work better to just drop the version from the
trigger altogether, and instead check if the old init script exists?
For example:
%triggerun -- httpd
[ -e %{_initddir}/httpd ] || exit 0
# rest of the migration stuff goes here
2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets,
only the final exit status of a script has any effect.
3) More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
11 years, 7 months
(C++) Header-Only Package
by Denis Arnaud
Hello,
we would like to package a C++ header-only project, namely tclap (
https://bugzilla.redhat.com/show_bug.cgi?id=683591).
The relevant guideline is to be found on:
https://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages
The question is:
1. Should the header files go into the main package, removing the need for a
-devel sub-package? The reason would be that that package is a development
package only, like gcc for instance.
2. Or should the header files go into the -devel sub-package, leaving the
main package almost empty (only the README, COPYING documentation would go
into the main package), much like what is done for Boost header-only
components?
In either case, then, since header files are architecture independent, I
guess that the corresponding package should be 'noarch'. However, a
pkgconfig (.pc) file is delivered together with the package; and rpmlint
complains that pkgconfig files should be delivered by architecture-dependent
sub-packages only. Should you leave rpmlint complaining quietly?
Thanks in advance
Best Regards
Denis
11 years, 8 months
anybody understand mingw's macros?
by Farkas Levente
hi,
i'm just fed up with this situation and try to debug this %mingw_cmake
macros and find out why not working.
since i can NOT find any kind of docs about rpm's macros! anybody know??
what and how %* works?
what is the %{nil} good for?
so what i find from /usr/lib/rpm/macros:
---------------------------
# The configure macro should be invoked as %configure (rather than
%{configure})
# because the rest of the arguments will be expanded using %*.
---------------------------
now i find the in /etc/rpm/macros.mingw %mingw_cmake before the
%mingw32_cmake call %* still contains the command line params. but since
%{mingw32_cmake} %*
called this way in stead of
%mingw32_cmake %*
the mingw32_cmake macro do not get the command line parameters. that's
why it's not possible to give the params further.
but if i rewrite the above two line than rpm macro deduction will fail
(i don't know why).
i try many different way tricks and trucks but none of them working.
anybody has any tip or anybody can help?
regards.
--
Levente "Si vis pacem para bellum!"
11 years, 8 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here are the latest changes to the Fedora Packaging Guidelines:
---
Some rpm versions pass pathnames to the automatic filtering macros, so a
section has been added to the guidelines to help packagers deal with it:
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering...
---
For a while, Fedora considered mono packages to be
architecture-specific, and installed assemblies to %{_libdir}. However,
after discussions with upstream, we now consider mono packages to be
architecture (and platform) independent. This means that mono packages
should be correctly installed into the GAC in /usr/lib or installed into
/usr/lib/PACKAGENAME.
As a notable exception, any ELF binary libraries generated in a mono
package must be correctly installed into %{_libdir}, because these files
are architecture-specific.
Also, even though we consider mono packages to be architecture
independent, they must not be marked as "noarch". Although the
assemblies are the same, the files may differ due to strings referring
to the build architecture.
https://fedoraproject.org/wiki/Packaging:Mono#File_Locations
---
It was decided that gnome shell extension packages should have the
prefix gnome-shell-extension (with no "s" on the end).
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_...
---
The section in the Fedora Packaging Guidelines concerning libexecdir has
been improved and expanded:
https://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir
---
The Fedora Java Packaging Guidelines have been updated to reflect the
latest macros for Maven 3.
https://fedoraproject.org/wiki/Packaging:Java
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Christian Krause, Aleksandar Kurtakov, Petr Pisar,
Stanislav Ochotnicky, and all of the members of the FPC, for assisting
in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
11 years, 8 months
Looking for packaging advice/mentor
by Steve Jenkins
Hi, I've been lurking on this list for a while now as I experiment
with packaging OpenDKIM (http://opendkim.org/), which is a milter
application for milter-aware MTAs (such as Postfix and Sendmail) to
sign and/or verify email with DKIM.
My goal is to make packages available for Fedora, EL5 and EL6. I've
got VMs set up for all those platforms (both 32- and 64-bit) and have
RPMs built. I'm now looking for someone who can give me some minor
guidance as to what to do next, and peek through what I've got so far
and provide feedback.
Thanks in advance for any assistance!
SteveJ
11 years, 8 months
rpmlint on Fedora and FHS
by Siem Korteweg
Hi,
Before I am going to package System Configuration Collector for Fedora, I
decided to run rpmlint on the existing, generic rpm of SCC.
SCC consists of 25 executable shell scripts that are installed in
/opt/scc/bin. Configuration files reside in /etc/opt/scc and data is
stored in /var/opt/scc/. All According to the FHS
(http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREP...).
Fedora follows the FHS
(http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout),
however, rpmlint reports errors for all scripts in /opt/scc/bin:
scc.noarch: E: dir-or-file-in-opt /opt/scc/bin/scc-log
A file in the package is located in /opt. It's not permitted for packages to
install files in this directory.
Why is it not permitted for packages to install files in /opt while that
is allright according to the FHS and Fedora follows FHS?
regards
Siem Korteweg
11 years, 8 months
Automatic dependency generation: gobject-introspection
by Matthias Clasen
The OpenSuSE folks have been working on automating dependency
information for use of libraries via gobject-introspection.
Their generators currently cover python and javascript, you can see them
here:
http://bugzilla.gnome.org/show_bug.cgi?id=654156
I'm really happy to see this being pushed upstream, and it will probably
land in rawhide with the next GLib release (in ~ 2 weeks) unless the
packaging committee has objections.
If we need to amend any packaging docs for this, let me know.
Matthias
11 years, 8 months
