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
Help with rpath issue
by Jirka Hladky
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to
check package review ticket at
https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but
libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is
missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
Thanks
Jirka
12 years, 10 months
Noarch package depending on an arch-specific package, how to handle it?
by Ville-Pekka Vainio
Hi,
I'm packaging pymtp, which the new gPodder versions need as a
dependency. The review request is at
<https://bugzilla.redhat.com/show_bug.cgi?id=643199>. It's a python
binding to libmtp done with ctypes. The package in itself is noarch, but
I noticed it won't work, if the 32-bit version of libmtp is installed on
a 64-bit system.
Should I make the pymtp package arch dependent and require the libmtp
package, which matches the arch? Or should I require "libmtp" and trust
yum to install the 64-bit package on x86_64? That wouldn't solve the
case where the system already has the 32-bit libmtp installed, though.
--
Ville-Pekka Vainio
12 years, 11 months
#15 relaxing guidelines wrt. bundling
by Jeroen van Meeuwen
Toshio Kuratomi wrote:
> If you're on packaging(a)lists.fp.o, we should probably take discussion
> there.
>
> Here's the fpc ticket with the question of whether we should relax the
> guidelines:
> https://fedorahosted.org/fpc/ticket/15
>
> Note that your description of the rubygem-passenger system could still fail
> to pass the test under revised guidelines depending on what they turn out
> to be. For instance, the guidelines might allow bundling of the latest
> upstream version or of the version provided by Fedora, or they might
> require that the package maintainer be able to code fixes should they be
> necessary. It's probably a good idea to join packaging(a)lists.fp.o and
> give reasons that requirements like that aren't needed.
>
As per the thread on advisory-board;
http://lists.fedoraproject.org/pipermail/advisory-board/2010-
October/009577.html
I urge you to consider to allow exceptions like these for the greater benefit
of your users -and thus upstream, through Fedora.
Kind regards,
Jeroen van Meeuwen
-kanarip
12 years, 11 months
Alternative plan for packages with bundled libraries
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I submitted this to the Advisory Board, but I'm including it here since
there's a lot of discussion ongoing about the nature of bundled
libraries in Fedora.
In the cases where removing libraries wouldn't be possible without
extensive upstream work, we should rewrite the rules around the use of
http://fedoraproject.org/wiki/Fedorapeople_Repos repositories to allow
such packages in an unofficial capacity. Right now, they require an
agreement that all packages being hosted meets with Fedora Packaging
Guidelines in full, but I suspect that the Board could consider reducing
this restriction to "In compliance with Fedora Legal guidelines"
instead. So we could at least have a central semi-official repository
where these packages could be made available to those who need them
(separate from Fedora and unsigned so those using them *know* they're
not official or fully-supported) while efforts are made to bring the
project into full compliance, at which time it should become an official
package.
The benefits of this would be that contentious packages could still have
a definitive delivery mechanism in keeping with Fedora's style. While
the package itself wouldn't fit into the official yum repositories, it
could still keep a set of maintainers (who would hopefully be actively
working with upstream to resolve the bundling issues at the same time).
The specific use-case I'm trying to address with this proposal was
brought up by Jeroen van Meeuwen on the Advisory Board mailing list. A
package like rubygen-passenger, which enjoys heavy use in the real
world, but can't be carried in Fedora due to a forked, bundled version
of the Boost utility library, could be carried in this unofficial
repository. Right now (according to Jeroen), it's very common for
deployments relying on this package to just roll their own from the
source tarball.
- From Jeroen's original email:
"This means that meanwhile, thousands of us downstream consumers run
rubygem-passenger customly built, packaged (maybe) and deployed to
production, whatever was the latest version when someone had a chance to
look for updates.
Bad, bad, bad. Very bad."
I think we definitely want Fedora users to be able to use a common
package for their deployments, even if it's not signed and carried in
the official repository.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzK6KgACgkQeiVVYja6o6OZ4gCePg6kXYMRTXQjF463WVhNSx31
t2YAnRUlF8c+oaUzFNXUKcjAG+H/JPPG
=wOAD
-----END PGP SIGNATURE-----
12 years, 11 months
Filled Seat on the Fedora Packaging Committee
by Tom Callaway
The Fedora Packaging Committee has filled its open seat. James Antill
has accepted the invitation to help Fedora improve and expand our
Packaging Guidelines.
This was a difficult decision, as we had many interested (and qualified)
candidates, and I would encourage any of them to attend and participate
in our public IRC meetings.
The Fedora Packaging Committee meets on Freenode IRC, in
#fedora-meeting, every Wednesday at 1600 UTC.
Thanks,
~spot
12 years, 11 months
who should own /usr/include/X11 ?
by Parag Nemade
Hi,
My rawhide installation shows me
$ yum provides /usr/include/X11
xorg-x11-proto-devel-7.4-39.fc15.noarch : X.Org X11 Protocol headers
Repo : rawhide
Matched from:
Filename : /usr/include/X11
xorg-x11-xtrans-devel-1.2.2-5.fc15.noarch : X.Org X11 developmental X
transport library
Repo : rawhide
Matched from:
Filename : /usr/include/X11
I also see xorg-x11-xbitmaps install header files in /usr/include/X11
but does not own that directory.
All 3 are individual(no dependency on each other) packages and should
own /usr/include/X11. Is it ok then all 3 to own it?
Parag.
12 years, 11 months
pvfs2
by Viji V Nair
Hi,
I would like to have pvfs2 filesystem bundled with fedora, can I join the
"Package Maintainers" group and follow the procedure. OR is there any issues
in including the file systems like this, reiser4 etc
Thanks & Regards
Viji
12 years, 11 months
