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?


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Karanbir Singh wrote:
> projects.centos.org solves this very problem
>
> 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
# Generated from imagesize-0.1.1.gem by gem2rpm -*- rpm-spec -*-
%define ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitelibdir']")
%define gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
%define gemname imagesize
%define geminstdir %{gemdir}/gems/%{gemname}-%{version}

Summary: measure image size(GIF, PNG, JPEG ,,, etc)
Name: rubygem-%{gemname}
Version: 0.1.1
Release: 1%{?dist}
Group: Development/Languages
License: Ruby
URL: http://imagesize.rubyforge.org
Source0: http://gems.rubyforge.org/gems/%{gemname}-%{version}.gem
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: rubygems
BuildRequires: rubygems
Provides: rubygem(%{gemname}) = %{version}

%description
measure image size(GIF, PNG, JPEG ,,, etc)


%prep

%build

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{gemdir}
gem install --local --install-dir %{buildroot}%{gemdir}
--force --rdoc %{SOURCE0}

%clean
rm -rf %{buildroot}

%files
%defattr(-, root, root, -)
%{gemdir}/gems/%{gemname}-%{version}/
%doc %{gemdir}/doc/%{gemname}-%{version}
%doc %{geminstdir}/README.txt
%{gemdir}/cache/%{gemname}-%{version}.gem
%{gemdir}/specifications/%{gemname}-%{version}.gemspec


%changelog
* Thu Jun 12 2008 Ralph Angenendt <ralph@centos.org> - 0.1.1-1
- Initial package
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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.


http://folkwolf.net/rubygems-1.3.1-1.src.rpm

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

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.

http://folkwolf.net/rubygems-1.3.1-1.src.rpm



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






_______________________________________________
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.noarch.rpm


Is the EPEL stuff able to be run under CentOS OK?

Oh, yes, absolutely.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Nov 19, 2008, at 6:52 AM, Ralph Angenendt wrote:


Karanbir Singh wrote:

projects.centos.org solves this very problem

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel