I built the following rpm. It requires ruby and ruby-libs to build. This version does not install the built-in rdoc and ri files for rubygems, as that requires a little more work than I have time for right now.
http://folkwolf.net/rubygems-1.3.1-1.src.rpm
HTH
Matt
Summary: RubyGem Name: rubygems Version: 1.3.1 Release: 1 requires: ruby >= 1.8.5, ruby-libs >= 1.8.5 Source0: %{name}-%{version}.tgz License: GPL URL: http://rubyforge.org/frs/download.php/45905/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch BuildPreReq: ruby >= 1.8.5, ruby-libs >= 1.8.5 Group: Development/Tools %description Ruby Gems
%prep %setup -q
%install ruby setup.rb --destdir $RPM_BUILD_ROOT/usr --no-rdoc --no-ri
cd $RPM_BUILD_ROOT find . -type d | sed '1,2d;s,^.,%attr(-,root,root) %dir ,' > $RPM_BUILD_DIR/file.list.%{name} find . -type f | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name} find . -type l | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name}
%files -f ../file.list.%{name} %clean rm -rf %{buildroot}
Matt Rose wrote:
requires: ruby >= 1.8.5, ruby-libs >= 1.8.5
Are you sure about that? I only have
Requires: ruby(abi) = 1.8
in my spec (which is for 1.1.1 though)
Source0: %{name}-%{version}.tgz License: GPL
I think naming both licenses is correct here:
License: Ruby License/GPL
BuildPreReq: ruby >= 1.8.5, ruby-libs >= 1.8.5
Hmmm. Why PreReq?
I have BuildRequires: ruby, ruby-irb, ruby-rdoc in my spec.
%description Ruby Gems
RubyGems is the Ruby standard for publishing and managing third party libraries.
Yours is a tad short :)
cd $RPM_BUILD_ROOT rm -rf %{buildroot}
Hmmm. Either or, I think. Not both in one spec file :)
I also have a wad of rubygems which are packaged and should be published somewhere (like a complete rails 2.1 environment, mod_passenger and other stuff).
Cheers,
Ralph
Ralph Angenendt wrote:
Matt Rose wrote:
requires: ruby >= 1.8.5, ruby-libs >= 1.8.5
Are you sure about that? I only have
Requires: ruby(abi) = 1.8
in my spec (which is for 1.1.1 though)
I don't think it actually requires ruby-libs, but the way I figure, they're going to need the ruby stdlib if they're going to actually install most gems. Better to set up the expectation in advance, IMO.
Source0: %{name}-%{version}.tgz License: GPL
I think naming both licenses is correct here:
License: Ruby License/GPL
BuildPreReq: ruby >= 1.8.5, ruby-libs >= 1.8.5
Hmmm. Why PreReq?
I have BuildRequires: ruby, ruby-irb, ruby-rdoc in my spec.
Because I forgot the syntax for BuildRequires
%description Ruby Gems
RubyGems is the Ruby standard for publishing and managing third party libraries.
Yours is a tad short :)
cd $RPM_BUILD_ROOT rm -rf %{buildroot}
Hmmm. Either or, I think. Not both in one spec file :)
good idea.
I also have a wad of rubygems which are packaged and should be published somewhere (like a complete rails 2.1 environment, mod_passenger and other stuff).
Cheers,
Ralph
we could put them up on github or I could host a publically available subver repo for ruby gem rpms, or something. It would be nice to have a central repo for exactly this kind of stuff. I wonder how hard it would be to do a gem2rpm script, like perl has with cpan2rpm.
Matt
Matt Rose wrote:
I also have a wad of rubygems which are packaged and should be published somewhere (like a complete rails 2.1 environment, mod_passenger and other stuff).
a Ruby SIG would be good to get going, we ( ralph and I ) spoke about this a while back. I have about 4 dozen rpms that could also go into this.
we could put them up on github or I could host a publically available subver repo for ruby gem rpms, or something. It would be nice to have a central repo for exactly this kind of stuff. I wonder how hard it would be to do a gem2rpm script, like perl has with cpan2rpm.
projects.centos.org solves this very problem :D
But we would need a standard for the specs to get adopted, and working with atleast the Fedora standards would be a good place to start.
So, is there interest in the ruby SIG ? and who wants to take ownership of spec sanity checking ?
Karanbir Singh wrote:
projects.centos.org solves this very problem :D
But we would need a standard for the specs to get adopted, and working with atleast the Fedora standards would be a good place to start.
So, is there interest in the ruby SIG ? and who wants to take ownership of spec sanity checking ?
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq
I'd be happy to take ownership, it's obviously something that's been on my mind lately. I think it'd be a good thing for both ruby and CentOS.
Matt
Karanbir Singh wrote:
projects.centos.org solves this very problem :D
But we would need a standard for the specs to get adopted, and working with atleast the Fedora standards would be a good place to start.
For gems I think adoption of the generated spec files from gem2rpm is quite okay - those specs look very clean. Find one attached.
So, is there interest in the ruby SIG ? and who wants to take ownership of spec sanity checking ?
Yes and Hmmm. >:)
Ralph
On Nov 19, 2008, at 6:52 AM, Ralph Angenendt wrote:
Karanbir Singh wrote:
projects.centos.org solves this very problem :D
But we would need a standard for the specs to get adopted, and working with atleast the Fedora standards would be a good place to start.
For gems I think adoption of the generated spec files from gem2rpm is quite okay - those specs look very clean. Find one attached.
The generated spec file is perhaps a little bit unnecessarily ornate.
For starters, I know of no reliable or wide-spread usage atm for Provides: ruby(foo) so feel free to use that rather than Provides: rubygems(foo)
A separate namespace for rubygems(...) is unlikely to be widely adopted imho, feel free to use ruby(...) instead.
Also please note that there is little reason to add ruby peculier Provides: for any reason yet. The world of RPM is littered with various Provides: that seemed like a good idea to someone but never actually caught on. If you do want to attempt ruby specific dependencies, focus on extracting Requires:, the Provides: are very easy to retrofit where needed once the Requires: reach a certain level of usage.
OTOH, additional Provides: wrapped in their own foo(bar) name space hurt nothing whatsoever.
But KISS is always better imho.
73 de Jeff
Matt Rose wrote:
central repo for exactly this kind of stuff. I wonder how hard it would be to do a gem2rpm script, like perl has with cpan2rpm.
there already is a gem2rpm script, and it works fine. I've churned the entire gem base in Feb 2008 to prove it. Some of the ri handing isnt ideal, but it works or is simple to patch out. I was lazy and only really wanted to sanity check and did not mind either ri or rdoc in the roots.
Karanbir Singh wrote:
Matt Rose wrote:
central repo for exactly this kind of stuff. I wonder how hard it would be to do a gem2rpm script, like perl has with cpan2rpm.
there already is a gem2rpm script, and it works fine. I've churned the entire gem base in Feb 2008 to prove it. Some of the ri handing isnt ideal, but it works or is simple to patch out. I was lazy and only really wanted to sanity check and did not mind either ri or rdoc in the roots.
The ri and rdoc handling needs some special care. IMHO the doc tree should go in /usr/share/doc, and I don't think that gems, or ruby are built to do that. I think that some kind of docs should go in /usr/share/doc (I hate installing rpms with no documentation), but installing docs in the correct location takes a little bit of brain scratching.
I found the gem2rpm rpm, I'll play with it in the coming days.
Matt
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Whoops, see comments in the previous email. Attached is the updated spec
Matt
Ralph Angenendt wrote:
Matt Rose wrote:
requires: ruby >= 1.8.5, ruby-libs >= 1.8.5
Are you sure about that? I only have
Requires: ruby(abi) = 1.8
in my spec (which is for 1.1.1 though)
Source0: %{name}-%{version}.tgz License: GPL
I think naming both licenses is correct here:
License: Ruby License/GPL
BuildPreReq: ruby >= 1.8.5, ruby-libs >= 1.8.5
Hmmm. Why PreReq?
I have BuildRequires: ruby, ruby-irb, ruby-rdoc in my spec.
%description Ruby Gems
RubyGems is the Ruby standard for publishing and managing third party libraries.
Yours is a tad short :)
cd $RPM_BUILD_ROOT rm -rf %{buildroot}
Hmmm. Either or, I think. Not both in one spec file :)
I also have a wad of rubygems which are packaged and should be published somewhere (like a complete rails 2.1 environment, mod_passenger and other stuff).
Cheers,
Ralph
Summary: RubyGem Name: rubygems Version: 1.3.1 Release: 1 requires: ruby >= 1.8.5, ruby-libs >= 1.8.5 Source0: %{name}-%{version}.tgz License: Ruby License/GPL URL: http://rubyforge.org/frs/download.php/45905/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch BuildRequires: ruby >= 1.8.5, ruby-libs >= 1.8.5 Group: Development/Tools
%description RubyGems is the Ruby standard for publishing and managing third party libraries
%prep %setup -q
%install ruby setup.rb --destdir $RPM_BUILD_ROOT/usr --no-rdoc --no-ri
cd $RPM_BUILD_ROOT find . -type d | sed '1,2d;s,^.,%attr(-,root,root) %dir ,' > $RPM_BUILD_DIR/file.list.%{name} find . -type f | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name} find . -type l | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name}
%files -f ../file.list.%{name} %clean rm -rf $RPM_BUILD_ROOT
On 11/18/2008 07:54 PM, Matt Rose wrote:
Whoops, see comments in the previous email. Attached is the updated spec
I've cleaned up a bit the spec, making it closer to the Fedora guidelines. It still has some errors because the list of files passed to % files includes the following files and directories which are already owned by other packages (and with no chance to be left unowned, should rubygems be uninstalled): /usr/bin (owned by filesystem) /usr/lib (owned by filesystem) /usr/lib/ruby (owned by ruby-libs) /usr/lib/ruby/site_ruby (owned by ruby-libs) /usr/lib/ruby/site_ruby/1.8 (owned by ruby-libs)
And last but not least, I think that a %test section would be nice to be included. Unfortunately I know no ruby at all, so I cannot create this part of the spec for you. And I am to busy^H^H^H^Hlazy to read the docs now.
Hope this helps.
Summary: RubyGem Name: rubygems Version: 1.3.1 Release: 1 Requires: ruby-libs >= 1.8.5 Source0: http://rubyforge.org/frs/download.php/45905/%%7Bname%7D-%%7Bversion%7D.tgz License: Ruby or GPLv2+ URL: http://rubyforge.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch BuildRequires: ruby >= 1.8.5 Group: Development/Tools
%description RubyGems is the Ruby standard for publishing and managing third party libraries
%prep %setup -q
%build #nothing to build
%install rm -rf $RPM_BUILD_ROOT ruby setup.rb --destdir $RPM_BUILD_ROOT/usr --no-rdoc --no-ri
cd $RPM_BUILD_ROOT find . -type d | sed '1,2d;s,^.,%attr(-,root,root) %dir ,' > $RPM_BUILD_DIR/file.list.%{name} find . -type f | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name} find . -type l | sed 's,^.,%attr(-,root,root) ,' >> $RPM_BUILD_DIR/file.list.%{name}
%clean rm -rf $RPM_BUILD_ROOT
%files -f ../file.list.%{name} %doc ChangeLog GPL.txt LICENSE.txt README TODO doc/
%changelog * Tue Nov 18 2008 Matt Rose <real mail should be here but I did not fill it on purpose> 1.3.1-1 - First version
Manuel Wolfshant wrote:
I've cleaned up a bit the spec, making it closer to the Fedora guidelines. It still has some errors because the list of files passed to % files includes the following files and directories which are already owned by other packages (and with no chance to be left unowned, should rubygems be uninstalled): /usr/bin (owned by filesystem) /usr/lib (owned by filesystem)
that 'find' has to die. the only way to put it is 'thats just wrong for every reasons'.
- KB
On 11/19/2008 03:10 AM, Karanbir Singh wrote:
Manuel Wolfshant wrote:
I've cleaned up a bit the spec, making it closer to the Fedora guidelines. It still has some errors because the list of files passed to % files includes the following files and directories which are already owned by other packages (and with no chance to be left unowned, should rubygems be uninstalled): /usr/bin (owned by filesystem) /usr/lib (owned by filesystem)
that 'find' has to die. the only way to put it is 'thats just wrong for every reasons'.
well put. but I am very very polite, am I not ?
PS: stuff like - rubygems.noarch: E: non-executable-script /usr/lib/ruby/site_ruby/1.8/rubygems/digest/md5.rb 0644 - rubygems.noarch: W: hidden-file-or-dir /usr/share/doc/rubygems-1.3.1/doc/release_notes/._rel_1_0_0.rdoc should probably be sanitized, too. maybe by killing all the old release notes?
On Nov 18, 2008, at 8:10 PM, Karanbir Singh wrote:
Manuel Wolfshant wrote:
I've cleaned up a bit the spec, making it closer to the Fedora guidelines. It still has some errors because the list of files passed to % files includes the following files and directories which are already owned by other packages (and with no chance to be left unowned, should rubygems be uninstalled): /usr/bin (owned by filesystem) /usr/lib (owned by filesystem)
that 'find' has to die. the only way to put it is 'thats just wrong for every reasons'.
Inconsistent with existing packaging practices and policies is perhaps more accurate.
There is nothing 'wrong' with having a directory owned by multiple packages no matter how many reasons you think you know.
73 de Jeff
Jeff Johnson wrote:
that 'find' has to die. the only way to put it is 'thats just wrong for every reasons'.
Inconsistent with existing packaging practices and policies is perhaps more accurate.
yes.
There is nothing 'wrong' with having a directory owned by multiple packages no matter how many reasons you think you know.
But if it can be avoided, for me its always worked best if that does not happen.
Also, I have a bigger problem with the generic 'find everything in there'; setting a finite expected list is way better. imho anyway.
- KB
Karanbir Singh wrote:
Also, I have a bigger problem with the generic 'find everything in there'; setting a finite expected list is way better. imho anyway.
Yes, as that one up there also finds .la files, if you don't remove them first. Well, not in this case, but ...
Cheers,
Ralph
On 11/17/2008 11:36 PM, Matt Rose wrote:
I built the following rpm. It requires ruby and ruby-libs to build. This version does not install the built-in rdoc and ri files for rubygems, as that requires a little more work than I have time for right now.
I've just noticed that rubygems-1.2.0 is in EPEL. I suggest getting in touch with the maintainer and kindly asking him to ship the newer version (he has not packaged 1.3.1 for Fedora either)
Huh, I was sure I looked at the epel repo. Is the EPEL stuff able to be run under CentOS OK?
Matt
Manuel Wolfshant wrote:
On 11/17/2008 11:36 PM, Matt Rose wrote:
I built the following rpm. It requires ruby and ruby-libs to build. This version does not install the built-in rdoc and ri files for rubygems, as that requires a little more work than I have time for right now.
I've just noticed that rubygems-1.2.0 is in EPEL. I suggest getting in touch with the maintainer and kindly asking him to ship the newer version (he has not packaged 1.3.1 for Fedora either) _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/19/2008 07:51 PM, Matt Rose wrote:
Huh, I was sure I looked at the epel repo.
http://cvs.fedoraproject.org/viewvc/rpms/rubygems/ http://download.fedora.redhat.com/pub/epel/5/i386/rubygems-1.2.0-2.el5.noarc...
Is the EPEL stuff able to be run under CentOS OK?
Oh, yes, absolutely.
On 19/11/2008, Matt Rose mrose@n-able.com wrote:
Huh, I was sure I looked at the epel repo. Is the EPEL stuff able to be run under CentOS OK?
With provisos. The CentOS wiki has some wise words on this subject . . . ;-)
See near the bottom of the page -- http://wiki.centos.org/AdditionalResources/Repositories
Alan.
Manuel Wolfshant wrote:
I've just noticed that rubygems-1.2.0 is in EPEL. I suggest getting in touch with the maintainer and kindly asking him to ship the newer version (he has not packaged 1.3.1 for Fedora either)
Considering EPEL isnt a part of CentOS, I'd still like to get the rubygems stuff into a CentOS repo - and also most of merb an rails if thats possible.
Karanbir Singh wrote:
Manuel Wolfshant wrote:
I've just noticed that rubygems-1.2.0 is in EPEL. I suggest getting in touch with the maintainer and kindly asking him to ship the newer version (he has not packaged 1.3.1 for Fedora either)
Considering EPEL isnt a part of CentOS, I'd still like to get the rubygems stuff into a CentOS repo - and also most of merb an rails if thats possible.
Rails is here. mod_passenger is also here - and as you and I already said: If someone needs a specific gem, it's no problem at all to provide one in a rather quick fashion.
Cheers,
Ralph
-
Alan Bartlett -
Jeff Johnson -
Karanbir Singh -
Manuel Wolfshant -
Matt Rose -
Ralph Angenendt