Docs outside %docdir
by Andrea Musuruane
Hi all,
I was performing a package review for RPM Fusion:
http://bugzilla.rpmfusion.org/show_bug.cgi?id=1153
RPM Fusion follows the Fedora Packaging Guidelines so I think I can
ask here a question it came to me during the review.
This package has some exec files correctly installed by the packager
in %libexecdir/packagename/bin instead of %libdir/packagename/bin
because they are called by the main program who sits in %bindir.
The files in %libexecdir use some files in
%libexecdir/packagename/doc to show help, options, examples, etc when
called with some parameters.
Is it acceptable to leave these files here? Or they should be moved
somewhere else?
They cannot be installed in %docdir because they affect the runtime of
the application:
https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation
Thanks in advance for you help.
Bye,
Andrea.
12 years, 10 months
Packaging-related changes in GNOME
by Matthias Clasen
This cycle, some things land in GNOME land that will require minor
adjustments of scriptlets:
1) GIO modules. GIO now uses a caching approach to its modules. If a
package installs a loadable module in %{_libdir}/gio/modules, you need
to run gio-querymodules to update
%{_libdir}/gio/modules/giomodule.cache. There's the usual multilib pain;
glib2 installs the binary as gio-querymodules-32/64. I propose to
recommend the following scriptlets for this:
%posttrans
gio-querymodules-%{__isa_bits} || :
%postun
gio-querymodules-%{__isa_bits} || :
2) GSettings. GConf is on the way out, we will start seeing applications
that are ported to GSettings (which is part of libgio in the glib2
package). GSettings uses schemas as well, and has a cache of those that
needs updating if schemas are added/removed. The tool for this is
glib-compile-schemas (schemas and their cache are arch-neutral, so no
multilib pain here). Proposed scriptlets:
%posttrans
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
%postun
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
3) GTK3. gtk3 will be parallel installable with gtk2, which means it
keeps its loadable modules separate. I took the occasion to rework
things a bit to reduce the multilib pain. gdk-pixbuf loaders, theme
engines and im modules get installed to
%{_libdir}/gtk-3.0/3.0.0/{loaders,engines,immodules}, and the cache
files for loaders and immodules have been relocated to
%{_libdir}/gtk-3.0/3.0.0/{loaders,immodules}.cache. Suitable scriptlets
to update these caches look as follows:
%posttrans
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
%postun
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
I guess all the %postun scriptlets could be optimized with a if $1 -eq 0
Comments ?
Matthias
12 years, 10 months
Requires for "lower" version of packages
by Mamoru Tasaka
Hello.
Now I am trying to see one of the review requests based on rubygems:
https://bugzilla.redhat.com/show_bug.cgi?id=652400
(This review request of just one example for rubygem related packages)
Rebuilding the srpm in this review ticket produces boxgrinder-build-0.6.4.gemspec
under /usr/lib/ruby/gems/1.8/specifications (this directory is normal
for .gemspec file) which contains:
---------------------------------------------------------
s.add_runtime_dependency(%q<commander>, ["~> 4.0.3"])
s.add_runtime_dependency(%q<boxgrinder-core>, ["~> 0.1.3"])
---------------------------------------------------------
Here "~> 4.0.3" means ">= 4.0.3 but < 4.1" ("~>" often appears in
rubygems). So in rpm spec world, this is interpreted as:
---------------------------------------------------------
Requires: rubygem(commander) >= 4.0.3
Requires: rubygem(commander) < 4.1
Requires: rubygem(boxgrinder-core) >= 0.1.3
Requires; rubygem(boxgrinder-core) < 0.2
---------------------------------------------------------
This is technically correct, however it seems that currently Fedora packaging
guideline mentions about higher version dependency (e.g.
https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires )
and I am not sure that it is allowed on Fedora to write dependency for
lower version. Any comments are appreciated.
By the way, currently the highest version of the upstream one is:
commander: 4.0.3
boxgrinder-core: 0.1.3
Regards,
Mamoru
12 years, 10 months
Co-maintaining packages - gdal, grass
by Viji V Nair
Hi,
I would like to co-maintain gdal and grass packages. I am working on
Fedora GIS spin:
We need to fix some issues in the above packages:
gdal : we care not shipping the jnis, java is broken and need to fix
grass : A very old GRASS version is packaged, it lacks more than 9000
fixes and enhancements with respect to the current stable version
which is GRASS 6.4.0
Please share your thoughts
Thanks
Viji
On Mon, Nov 15, 2010 at 11:08 PM, Viji V Nair <viji(a)fedoraproject.org> wrote:
> Hi,
>
> I am working on geoserver package for fedora. For the same I would
> require the following libraries, those are not included in the gdal
> package, is there any specific reason to exclude the same? can you
> please let me know ?
>
> libgdaljni.so libogrjni.so libgdalconstjni.so libosrjni.so
>
> Thanks
> Viji
>
12 years, 10 months
Prefix for database add-on packages?
by Michel Alexandre Salim
I'm currently reviewing pgRouting:
https://bugzilla.redhat.com/show_bug.cgi?id=652533
the packager is currently using "postgresql-pgrouting" as the name, which
is alright but a bit long. There does not seem to be a policy for naming
DB add-ons yet (though I see a couple of postgresql-* packages).
Would the same policy applied as to, say, the Python add-ons? e.g.
"if the name starts with [pP]y then you don't need the python- prefix".
In this case, "pg" would clearly indicate that it's to be used with
PostgreSQL.
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12 years, 10 months