Filtering automatic provides
by Vít Ondruch
Hi Rubyists,
Binary ruby- and rubygem- packages ships .so files. These .so files are
picked up by RPM's automatic Requires/Provides generater and they are
listed among provides, e.g.:
$ repoquery -q --provides rubygem-sqlite3
rubygem(sqlite3) = 1.3.5-4.fc19
rubygem-sqlite3 = 1.3.5-4.fc19
rubygem-sqlite3(x86-64) = 1.3.5-4.fc19
sqlite3_native.so()(64bit)
However, these .so files are not useful outside of Ruby world and they
might even conflict with some system library (although I don't have any
example at my hand currently). So I believe, we should filter out these
automatic provides, as is done in Perl for example. Therefore, since
F19, there are available %{?ruby_default_filter} and
%{?rubygems_default_filter} macros, which allow to filter out these
provides.
For your curiosity, this is their implementation:
%ruby_default_filter %{expand: \
%global __provides_exclude_from
%{?__provides_exclude_from:%{__provides_exclude_from}|}^(%{ruby_vendorarchdir}|%{ruby_sitearchdir})/.*\\\\.so$
\
}
%rubygems_default_filter %{expand: \
%global __provides_exclude_from
%{?__provides_exclude_from:%{__provides_exclude_from}|}^%{gem_extdir_mri}/.*\\\\.so$
\
}
If nobody objects, I am going to propose usage of these macros into Ruby
packaging guidelines [1].
Vít
[1]
https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&diff=351...
10 years, 2 months
Need some help writing gitlab and gitlab-shell specs
by Achilleas Pipinellis
Cross posting this in ruby-sig since this concerns ruby packaging and in
devel since I have some more generic questions. Excuse me if I created
unecessary noise. For those not familiar with the project, you'll find
some info here [http://axilleas.me/tag/gsoc.html].
Let me start with the directory structure of these packages.
We have two locations:
1) where the main gitlab and gtlab-shell rails apps reside,
2) where git repositories and their satellites[0] are.
I have asked in #fedora-infra what FHS they use with the git repos in
fedorahosted and we concluded that the rails apps would go to
/usr/share/ and git repos and satellites to /usr/lib/. Now, when
specifing %{_libdir} in a spec, it gets /usr/lib64/ on a x86_64 machine.
I wouldn't want to install gitlab in different dirs when different
arches, so for now I used /var/lib/ for that purpose. I guess I could
excplicitly say /usr/lib/gitlab/ but anyway.
So the current structure is:
|-- /usr/share/gitlab/
| |-- gitlab/
| |-- gitlab-shell/
|
|-- /var/lib/gitlab/
| |-- satellites/
| |-- repositories/
| |-- .ssh/authorized_keys
|
|-- /etc/gitlab/
| |-- gitlab.yml
| |-- shell.yml
| |-- database.yml
| |-- unicorn.rb
In /etc there will be configuration files with symlinks in the rails app
dirs. What are your thoughts on the directory locations? Do you agree?
And now my questions about the specs.
FYI I have seen the katello.spec and took some info from there[1].
gitlab-shell.spec
-----------------
This is kinda finished.
SPEC:
https://github.com/axilleas/fedora/blob/master/packages/gitlab-shell/gitl...
I tested the package and the appropriate user and group are created when
install/upgrade but when uninstalling, the homedir doesn't get removed.
I suspect this has something to do with useradd and protecting the
homedir of the user?
gitlab.spec
-----------
This is a draft, I didn't test to install yet.
SPEC:
https://github.com/axilleas/fedora/blob/master/packages/gitlab/gitlab.spec
## Ruby specific
- rake tasks
Many jobs, like the backup, initial database seed, etc. are done with
rake tasks. How do we invoke them without getting in the app root dir
every time? Is there some sort of mechanism for that?
- Are Gemfile and Gemfile.lock really needed for the app to work? If yes
how can we avoid this? Using bundler_ext? If yes, how?
This is an interesting question as katello uses bundler_ext but I
haven't yet understood how that works. Any tip would be appreciated. For
now, in the test instance I set up, unicorn checks the Gemfile and if
not found it doesn't spawn. Here is an entry in its log when I removed
the Gemfile:
I, [2013-09-19T21:00:13.056391 #18224] INFO -- : Refreshing Gem list
and then an error occured.
## Generic
- symlink logs to /var/log/gitlab/
Not all logs' directory is configurable. GitLab uses the logs found in
app_dir/log/ and displays them via its ui to the admin users. Should I
symlink these logs to /var/log/ for ease of access?
- pids: move to /var/run/gitlab/ (?)
GitLab is practically running using unicorn and sidekiq. These two
create each its own pid file in app_dir/tmp/pids/ by default. Luckily
this is configurable via their configs or systemd services. Also unicorn
creates a gitlab.socket which uses to speak with the app. If we use
apache this isn't needed, but with nginx we can use it. I was thinking
it could go under /var/run/gitlab/ too.
- how to support both databases. Is it feasible?
GitLab supports mysql(mariadb for us) and postgres. How do we deal with
these cases inside a spec file? For now, I have added a comment about
the postgres config and made mariadb the default one.
- ownership of directories
In upstream installation guide, gitlab and gitlab-shell reside in the
same location that's why I decided to have them both under
/usr/share/gitlab/. And my question is, which package owns
/usr/share/gitlab/? Both?
Thanks for reading, it took me quite a few hours to compose :)
[0] satellites is a directory where it is stored information about the
merge requests, forks, etc of each git repository.
[1]
https://github.com/axilleas/fedora/blob/master/packages/SPECS/katello.spec
--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me
10 years, 2 months
/usr/share/gems/doc ownership
by Ken Dreyer
jvcelak recently pointed out that the rubygems package does not own
/usr/share/gems/doc . This was news to me. I guess this changed
earlier this year:
commit 1d350ea912e72d30c7d079449db926ed4cb652a9
Author: TASAKA Mamoru <mtasaka(a)localhost.localdomain>
Date: Mon Feb 25 18:05:45 2013 +0900
Split out ri-generated documentation
I have a workstation that I updated from Fedora 17 to 19, and while I
don't have rubygems-doc installed, I still have a /usr/share/gems/doc
directory on this computer:
$ rpm -qf /usr/share/gems/doc
file /usr/share/gems/doc is not owned by any package
So this looks like something broke there :(
My bigger question is what to do about the Fedora Package Guidelines.
jvcelak pointed out that the requirement "Package must own all
directories that it creates" means that simply installing "rubygems"
is no longer enough to satisfy the dependency for my rubygem's -doc
subpackage. All rubygem-*-doc subpackages must now also require
rubygems-doc in order to comply with this guideline. (I have confirmed
that adding Requires: rubygems-doc to my -doc subpackage will silence
the warning from fedora-review.)
Can we please make the main rubygems RPM provide an empty %dir
/usr/share/gems/doc? This would avoid the need to change all the
rubygems packages that ship a -doc subpackage. It would also avoid the
unnecessary installation of rubygems-doc whenever installing a single
gem's -doc subpackage.
- Ken
10 years, 2 months
Bringing GitLab in Fedora
by Axilleas Pipinellis
Hello dear list!
I am applying for this year's GSOC [0] and I would like to contribute by
bringing GitLab [1][2] in Fedora. For those that don't already know
GitLab, it is a Self hosted Git management software written on Ruby on
Rails, pretty much like github's interface (you can try a demo here [3]).
It is a ruby app with lots of dependencies and I think this is a great
opportunity to extend the list of packaged gems supported by Fedora. Let
alone the fact that with the momentum GitLab has gained (it is in the
top 50 most popular open source projects on github) it would be an asset
if Fedora had this packaged. Also, the core developer was more than
willing to help with the process [4].
I could use any help needed on packaging. I have already exchanged a
couple of mails with Vit Ondruch and he pointed me to a direction. In
fact I am in the middle of reading all the related stuff from the wiki.
So what are your thoughts? Any guidance, ideas or insights are very much
appreciated!
Regards,
Axilleas
PS. There is also the thought of deploying GitLab to git repositories on
fedorahosted.org, but that's irrelevant to this list.
[0] https://fedoraproject.org/wiki/GSOC_2013
[1] http://gitlab.org
[2] https://github.com/gitlabhq/gitlabhq
[3] http://demo.gitlabhq.com/
[4] https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/SQMDi-yyXmU
10 years, 2 months