FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 02-28-2012, 03:56 PM
Vít Ondruch
 
Default New packaging guidelines for Ruby

Dne 28.2.2012 17:43, Rex Dieter napsal(a):

On 02/28/2012 10:36 AM, Vít Ondruch wrote:

May be you could elaborate a bit what do you want to achieve and what is
the reasoning. What do you mean by "not building from (preferred form)
source" anyway?


So, perhaps I'm showing some ignorance here. Do these guidelines
allow for packaging pre-built gems (similar to pre-built java .jar
files) or are they genuinely being built completely from source?


Maybe I'm confusing that with gems being built and generated in one
step, rather than the rpm notion of extracting source/patching
(%prep), building stuff (%build), and installing into buildroot
(%install).


-- rex
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging


Ok, I'll give you 3 examples:

= Old guidelines, used from the time RubyGems were packaged for Fedora =

%prep

%build

%install
mkdir -p %{buildroot}%{gem_dir}
gem install --local --install-dir %{buildroot}%{gem_dir}
--force %{SOURCE0}




= What we are proposing =

%prep
%setup -q -c -T
mkdir -p .%{gem_dir}
gem install --local --install-dir .%{gem_dir}
--force %{SOURCE0}

%build

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/*
%{buildroot}%{gem_dir}/




= What FPC is proposing =

%prep
%setup -q -c -T
pushd ..
gem unpack %{SOURCE0}

pushd %{gem_name}-%{version}
gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec

gem build %{gem_name}.gemspec
popd
popd

%build
mkdir -p ./%{gem_dir}
gem install --local --install-dir ./%{gem_dir}
--force ../%{gem_name}-%{version}/%{gem_name}-%{version}.gem

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/*
%{buildroot}%{gem_dir}/


All three versions provide the same output, unless I did some mistake,
since I did not tested it (actually the middle one was taken directly
from rubygem-POpen4.spec). So which version you prefer? Please note that
the "gem install" will always "unpack" the gem with some additional, for
our case unimportant, steps. We do not distribute the .gem file anywhere.



Vit
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2012, 04:05 PM
Rex Dieter
 
Default New packaging guidelines for Ruby

On 02/28/2012 10:56 AM, Vít Ondruch wrote:



All three versions provide the same output, unless I did some mistake,
since I did not tested it (actually the middle one was taken directly
from rubygem-POpen4.spec). So which version you prefer? Please note that
the "gem install" will always "unpack" the gem with some additional, for
our case unimportant, steps. We do not distribute the .gem file anywhere.


You didn't exactly (directly) answer my question. Pretend I don't know
much about ruby... (not far from the truth).


So, for rubygem packages that include native (C or otherwise code), how
and when is this compiled? If it is always done so during either
version of these guidelines, please do accept my apologies for being
ignorant.


However, you do say you do not distribute the .gem, though I'm curious
why this seem to contradict you:


rpm -qlp rubygem-POpen4-0.1.4-3.fc17.noarch.rpm
/usr/share/gems/cache/POpen4-0.1.4.gem
...

-- rex
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2012, 04:25 PM
Vít Ondruch
 
Default New packaging guidelines for Ruby

Dne 28.2.2012 18:05, Rex Dieter napsal(a):
On
02/28/2012 10:56 AM, Vít Ondruch wrote:







All three versions provide the same output, unless I did some
mistake,


since I did not tested it (actually the middle one was taken
directly


from rubygem-POpen4.spec). So which version you prefer? Please
note that


the "gem install" will always "unpack" the gem with some
additional, for


our case unimportant, steps. We do not distribute the .gem file
anywhere.





You didn't exactly (directly) answer my question.* Pretend I don't
know much about ruby... (not far from the truth).




So, for rubygem packages that include native (C or otherwise
code), how and when is this compiled?* If it is always done so
during either version of these guidelines, please do accept my
apologies for being ignorant.





It is compiled during the "gem install" step. So "gem install" is
doing %prep, %build, %install in one step. So yes, it is always done
for either version of guidelines.






However, you do say you do not distribute the .gem, though I'm
curious why this seem to contradict you:




rpm -qlp rubygem-POpen4-0.1.4-3.fc17.noarch.rpm


/usr/share/gems/cache/POpen4-0.1.4.gem


...







I knew you will point it out .



It is cached version of the original gem, which RubyGems may use to
restore the gem into its original state (and may be other unknown
purposes). However, it is not used in runtime, nor it is good idea
to restore the gems maintained by RPM by gem command. Moreover, even
though the gem would not be available in the cache dir, RubyGems
will download it. Hence we add new clause into the packaging
guidelines:



Since the Gem is installed using RPM, you must exclude the
.gem file.





Vit







--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2012, 05:23 PM
Vít Ondruch
 
Default New packaging guidelines for Ruby

Dne 28.2.2012 18:36, Michal Fojtik napsal(a):

On Feb 28, 2012, at 6:25 PM, Vít Ondruch wrote:


Dne 28.2.2012 18:05, Rex Dieter napsal(a):

On 02/28/2012 10:56 AM, Vít Ondruch wrote:


All three versions provide the same output, unless I did some mistake,
since I did not tested it (actually the middle one was taken directly
from rubygem-POpen4.spec). So which version you prefer? Please note that
the "gem install" will always "unpack" the gem with some additional, for
our case unimportant, steps. We do not distribute the .gem file anywhere.

You didn't exactly (directly) answer my question. Pretend I don't know much about ruby... (not far from the truth).

So, for rubygem packages that include native (C or otherwise code), how and when is this compiled? If it is always done so during either version of these guidelines, please do accept my apologies for being ignorant.

It is compiled during the "gem install" step. So "gem install" is doing %prep, %build, %install in one step. So yes, it is always done for either version of guidelines.


However, you do say you do not distribute the .gem, though I'm curious why this seem to contradict you:

rpm -qlp rubygem-POpen4-0.1.4-3.fc17.noarch.rpm
/usr/share/gems/cache/POpen4-0.1.4.gem
...


I knew you will point it out .

It is cached version of the original gem, which RubyGems may use to restore the gem into its original state (and may be other unknown purposes). However, it is not used in runtime, nor it is good idea to restore the gems maintained by RPM by gem command. Moreover, even though the gem would not be available in the cache dir, RubyGems will download it. Hence we add new clause into the packaging guidelines:

gem help commands

pristine Restores installed gems to pristine condition from files
located in the gem cache
unpack Unpack an installed gem to the current directory

AFAIK this is the reason gem files are kept in cache dir. I barely understand how 'pristine' command
could be dangerous to RPM (personally I think it can be useful when you make some dirty modification
to installed gem directly as root (trying to debug/solve some issue)).

If the case is that we don't want to keep these files on filesystem, then these two commands should
be 'patched' out from the 'gem' command or some decent warning to user should be provided.


Since the gems managed by RPM are no longer in GEM_HOME, neither the
"gem pristine" nor "gem unpack" can touch them. If you want to
reinstall RPM nanaged gem, you should use something like "yum reinstall
rubygem-foo" or alternatively "rpm -i --force rubygem-foo.rpm".


"gem pristine" and "gem unpack" will work no matter if the .gem file is
kept in cache or not. In the rare case you need them, the .gem files
will be downloaded from rubygems.org. That is a beauty of cache, you
can loose it and it will not hurt.



Vit
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 09:50 AM
"Nicolas Mailhot"
 
Default New packaging guidelines for Ruby

Le Mar 28 février 2012 16:29, Vít Ondruch a écrit :

> Pleas do not be mistaken. We are not speaking about building gems from
> sources. We are speaking about building from package manager output,
> i.e. build gem from gem.

So we are shipping stuff, which is not build from other stuff we ship, but
from magic upstream binaries? Not nice at all.

--
Nicolas Mailhot

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 10:01 AM
Bohuslav Kabrda
 
Default New packaging guidelines for Ruby

----- Original Message -----
>
> Le Mar 28 février 2012 16:29, Vít Ondruch a écrit :
>
> > Pleas do not be mistaken. We are not speaking about building gems
> > from
> > sources. We are speaking about building from package manager
> > output,
> > i.e. build gem from gem.
>
> So we are shipping stuff, which is not build from other stuff we
> ship, but
> from magic upstream binaries? Not nice at all.
>
> --
> Nicolas Mailhot

Well, the .gem files are not binaries, they are tar simply files and also contain files with some metadata.
When you call the "gem install --local foo %{SOURCE0}", it takes the .gem file, untars it and produces some necessary files (like .gemspec file) from the metadata.
This is the reason why we feel that rebuilding is not necessary. It doesn't make sense to untar the source, then tar it and finally untar it again (without actually doing something with it) and use the "gem install" command anyway, as now written in [1]. The output is _exactly_ the same as in our proposal, but you need twice the steps to do it.

--
Regards,
Bohuslav "Slavek" Kabrda.

[1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Building_gems
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 10:18 AM
Emanuel Rietveld
 
Default New packaging guidelines for Ruby

On 02/29/2012 11:50 AM, Nicolas Mailhot wrote:


Le Mar 28 février 2012 16:29, Vít Ondruch a écrit :


Pleas do not be mistaken. We are not speaking about building gems from
sources. We are speaking about building from package manager output,
i.e. build gem from gem.


So we are shipping stuff, which is not build from other stuff we ship, but
from magic upstream binaries? Not nice at all.



It is worth noting that .java files compiled into .class files or .jar
files is not the same thing as .rb files. .rb files are not compiled*


Gem can be compared to an RPM that contains only python files for
example. The source is the same as the end result, just packaged up.


You can definitely question if .gem files are in the 'preferred form for
editing' or not, but at least, it goes a bit far too call it a magic binary.


* Some gems contain native extensions. These are packaged in the gem in
source code form, and compiled when the gem is installed, or in our
case, when the binary RPM is built.

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 10:43 AM
Mo Morsi
 
Default New packaging guidelines for Ruby

> Ok, I'll give you 3 examples:
>
> = Old guidelines, used from the time RubyGems were packaged for Fedora =
>
> %prep
>
> %build
>
> %install
> mkdir -p %{buildroot}%{gem_dir}
> gem install --local --install-dir %{buildroot}%{gem_dir}
> --force %{SOURCE0}
>
>
>
>
> = What we are proposing =
>
> %prep
> %setup -q -c -T
> mkdir -p .%{gem_dir}
> gem install --local --install-dir .%{gem_dir}
> --force %{SOURCE0}
>
> %build
>
> %install
> mkdir -p %{buildroot}%{gem_dir}
> cp -a .%{gem_dir}/*
> %{buildroot}%{gem_dir}/
>
>
>
>
> = What FPC is proposing =
>
> %prep
> %setup -q -c -T
> pushd ..
> gem unpack %{SOURCE0}
>
> pushd %{gem_name}-%{version}
> gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
>
> gem build %{gem_name}.gemspec
> popd
> popd
>
> %build
> mkdir -p ./%{gem_dir}
> gem install --local --install-dir ./%{gem_dir}
> --force ../%{gem_name}-%{version}/%{gem_name}-%{version}.gem
>
> %install
> mkdir -p %{buildroot}%{gem_dir}
> cp -a .%{gem_dir}/*
> %{buildroot}%{gem_dir}/
>
>
> All three versions provide the same output, unless I did some mistake,
> since I did not tested it (actually the middle one was taken directly
> from rubygem-POpen4.spec). So which version you prefer? Please note
> that the "gem install" will always "unpack" the gem with some
> additional, for our case unimportant, steps. We do not distribute the
> .gem file anywhere.

Alternatively we can go with a hybrid of solutions 2 and 3 (your and
FPC's proposals) where the 'gem unpack' and 'gem spec' steps are optional.

The majority of gems do not need an additional modification or patching
to be converted into a RPM. Yes these steps bring things more inline w/
other packages, but at the expense of unnecessary additional work.

If the solution is to suggest gem unpack / gem spec is used while
allowing for it to be omitted (still need to determine if gem install
should still be run in the %build or %install sections), package
maintainers will have a bit more flexibility to run the steps necessary
to build their package w/out any additional work, while at the same time
still being more compliant and in-line w/ other Fedora practices.

Thoughts?

As a side node, if at all possible, please make sure to cc' both lists
(packaging and ruby-sig) on replies as this discussion is relevant to
both communities. Noticed alot of discussion only on the packaging list
meaning the Fedora ruby community is missing out on alot of this.

Appreciate it,

-Mo



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 11:21 AM
Vít Ondruch
 
Default New packaging guidelines for Ruby

Dne 29.2.2012 12:43, Mo Morsi napsal(a):

Ok, I'll give you 3 examples:

= Old guidelines, used from the time RubyGems were packaged for Fedora =

%prep

%build

%install
mkdir -p %{buildroot}%{gem_dir}
gem install --local --install-dir %{buildroot}%{gem_dir}
--force %{SOURCE0}




= What we are proposing =

%prep
%setup -q -c -T
mkdir -p .%{gem_dir}
gem install --local --install-dir .%{gem_dir}
--force %{SOURCE0}

%build

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/*
%{buildroot}%{gem_dir}/




= What FPC is proposing =

%prep
%setup -q -c -T
pushd ..
gem unpack %{SOURCE0}

pushd %{gem_name}-%{version}
gem spec %{SOURCE0} -l --ruby> %{gem_name}.gemspec

gem build %{gem_name}.gemspec
popd
popd

%build
mkdir -p ./%{gem_dir}
gem install --local --install-dir ./%{gem_dir}
--force ../%{gem_name}-%{version}/%{gem_name}-%{version}.gem

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/*
%{buildroot}%{gem_dir}/


All three versions provide the same output, unless I did some mistake,
since I did not tested it (actually the middle one was taken directly
from rubygem-POpen4.spec). So which version you prefer? Please note
that the "gem install" will always "unpack" the gem with some
additional, for our case unimportant, steps. We do not distribute the
.gem file anywhere.

Alternatively we can go with a hybrid of solutions 2 and 3 (your and
FPC's proposals) where the 'gem unpack' and 'gem spec' steps are optional.


Yes, that was always part of the proposal. Apply the 3rd step only if
necessary.


Vit



The majority of gems do not need an additional modification or patching
to be converted into a RPM. Yes these steps bring things more inline w/
other packages, but at the expense of unnecessary additional work.

If the solution is to suggest gem unpack / gem spec is used while
allowing for it to be omitted (still need to determine if gem install
should still be run in the %build or %install sections), package
maintainers will have a bit more flexibility to run the steps necessary
to build their package w/out any additional work, while at the same time
still being more compliant and in-line w/ other Fedora practices.

Thoughts?

As a side node, if at all possible, please make sure to cc' both lists
(packaging and ruby-sig) on replies as this discussion is relevant to
both communities. Noticed alot of discussion only on the packaging list
meaning the Fedora ruby community is missing out on alot of this.

Appreciate it,

-Mo





--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-29-2012, 01:23 PM
Stanislav Ochotnicky
 
Default New packaging guidelines for Ruby

Quoting Emanuel Rietveld (2012-02-29 12:18:57)
>On 02/29/2012 11:50 AM, Nicolas Mailhot wrote:
>>
>> Le Mar 28 février 2012 16:29, Vít Ondruch a écrit :
>>
>>> Pleas do not be mistaken. We are not speaking about building gems from
>>> sources. We are speaking about building from package manager output,
>>> i.e. build gem from gem.
>>
>> So we are shipping stuff, which is not build from other stuff we ship, but
>> from magic upstream binaries? Not nice at all.
>>
>
>It is worth noting that .java files compiled into .class files or .jar
>files is not the same thing as .rb files. .rb files are not compiled*

However I have seen gem files containing bundled jar files. Not sure if
gem unpacking actually helps things, but it might make it more easy to
spot perhaps. There as easy ways to detect such bundling though, so not
a problem. Just though I'd mention this use case

--
Stanislav Ochotnicky <sochotnicky@redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 12:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org