[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Some changes to the Fedora Packaging Guidelines have been made:
---
If a package is exempt from multilib, it may use %{_prefix}/lib instead
of %{_libdir}. Packages that contain architecture specific files that
would ordinarily be installed into %{_libexecdir} are always considered
ineligible for multilib. However, you should be sure that the
(sub)package that they are in does not have other content that would be
considered eligible for multilib. If this is not the case for the files
you wish to do this in for your package or you are just unsure, ask
FESCo for an explicit multilib exemption.
https://fedoraproject.org/wiki/Packaging:Guidelines#Multilib_Exempt_Locat...
Please note that FESCo granted an explicit exemption for systemd (and
any packages with systemd unit files) to use %{_prefix}/lib/systemd.
The core systemd packages were also given permission to be excluded from
multilib.
---
The section of the Guidelines covering how to handle Troublesome URLs in
SourceURL fields has been amended:
https://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs
Additionally, a new section has been added to cover how to handle GitHub
source files:
https://fedoraproject.org/wiki/Packaging:SourceURL#Github
---
The Java packaging guidelines were updated for the following changes:
* No longer require 2+ jars to be in subdirectory (there was no
technical need)
* Add standardization for compatibility packages
* Remove no longer needed parts about Maven 2
* Improve add_maven_depmap documentation
* Add suggestions for pom_ macros instead of patching
* installation/use of J2EE APIs standardization (initial version)
* JNI guidelines simplification & examples
https://fedoraproject.org/wiki/Packaging:Java
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to leamas, Stanislav Ochotnicky (and the Java SIG), Kamil
Páral, 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,
~tom
11 years, 3 months
purpose of ruby(abi), python(abi), etc
by Vít Ondruch
Hi,
Can somebody enlighten me, what is the purpose of ruby(abi) (replace by
python(abi) if you wish) virtual provide? Especially, why Ruby packaging
guidelines mandate "Requires: ruby(abi) = 1.9.1", i.e. versioned
require? And why in Python packages, python(abi) is automatically generated?
If the package is noarch, there is very high chance, that it would work
with Ruby 1.8 as good as with Ruby 1.9 or even Ruby 2.0. If the package
is arch dependent, it has automatically generated dependency on
libruby.so.1.9. So there is no chance to install it or run it with other
version of Ruby.
Now why I am asking? We would like to have in F19 Ruby 2.0 accompanied
by JRuby 1.7 and in the future, we would love to see these interpreters
interchangeable, i.e. it doesn't matter which interpreter is on your
system, since it will be able to run the gem/application shipped in
Fedora. However, while Ruby 2.0 should provide "ruby(abi) = 2.0", JRuby
are not yet fully 2.0 ready, so they should not provide "ruby(abi) =
2.0". Moreover, the term ABI with JRuby is a bit misleading.
So how we can make every noarch ruby package compatible with both
interpreters in terms of requires? One possibility would be to drop the
abi version unless it is explicitly needed. However, it renders
ruby(abi) as not the best virtual provide name for this goal.
Any ideas?
Vít
11 years, 3 months
Directory ownership question
by Linux Linux
Hi,
I package the gogui and pentobi game and i have fall on a directory ownership problem :
%{_datadir}/thumbnailers/%{name}.thumbnailer
or /usr/share/thumbnailers is owned by nobody
rpm -qf /usr/share/thumbnailers
le fichier /usr/share/thumbnailers n'appartient à aucun paquetage (package owned by nobody)
Or thumbnailers directory has other programms
ll /usr/share/thumbnailers
total 28
drwxr-xr-x. 2 root root 4096 23 nov. 11:31 .
drwxr-xr-x. 307 root root 12288 12 déc. 14:26 ..
-rw-r--r--. 1 root root 490 24 avril 2012 evince.thumbnailer
-rw-r--r--. 1 root root 1304 13 nov. 15:35 gsf-office.thumbnailer
-rw-r--r--. 1 root root 1731 4 juil. 2012 totem.thumbnailer
Is it normal that this /usr/share/thumbnailers is orphan ?
Need we let him orphan ?
Thanks in advance
-- Chris
11 years, 3 months
Ruby vs. JRuby - alternatives or not?
by Bohuslav Kabrda
Hi all,
as I'm working on packaging new JRuby for F19, I've started thinking about approach to coexistence of JRuby and cRuby - and I'd like to hear some opinions on that.
On the first look, cRuby and JRuby seem to be an appropriate candidates for using alternatives (which solves the problem of automatically generated dependencies from shebangs and switching interpreters by root). But - thinking of it further, I'm not sure whether cRuby and JRuby are alternatives. Reasons:
1. extension gems - there are gems with extensions
a) only for cRuby
b) only for JRuby
c) for both implementations.
Obviously, most of the cRuby-only extension gems are only usable with cRuby and vice versa for JRuby (exceptions are gems that contain pure Ruby fallback when extension cannot be loaded). For these extension gems, cRuby and JRuby are not alternatives, AFAICS.
2. pure Ruby gems using cRuby specific functions - some Ruby functions, for example fork(), cannot be used on JRuby, because JRuby doesn't support fork() - so if a gem uses fork, it only works on cRuby.
So cRuby and JRuby are mostly alternatives, but not completely. Therefore we (ruby-sig folks) came up with an idea that we call multiruby [1], which allows user (a user who knows what he's doing - for RPM packaged applications, packager will choose how to run them, possibly modifying shebangs) to choose the interpreter on invocation. The intepreter defaults to cRuby (also, compared to alternatives, this approach brings the benefit on non-root user being able to choose/switch the interpreter). In this scheme, /usr/bin/ruby would be a shell script that would route the commands either to /usr/bin/ruby-mri or /usr/bin/jruby. I know that this is no standard mechanism, but it doesn't break any expectations and brings some interesting functionality.
For example
ruby foo.rb # behaves as it now does
gem install foo # behaves as it now does
ruby _jruby_ foo.rb # invokes foo.rb with jruby
gem _jruby_ install foo # runs "gem install" with jruby
The inspiration for this approach is actually taken from RubyGems binary wrappers (as documented in [2]). The wrappers let you choose gem version on the wrapper execution, e.g. "rake _0.7.3_" will run rake 0.7.3, so the multiruby concept would not be anything strange to Ruby folks.
Thoughts? Would this be an acceptable approach?
Thanks.
[1] https://github.com/bkabrda/multiruby
[2] http://guides.rubygems.org/command-reference/#gem_install, section about wrappers
--
Regards,
Bohuslav "Slavek" Kabrda.
11 years, 3 months
