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, 11:47 AM
Bohuslav Kabrda
 
Default New packaging guidelines for Ruby

----- Original Message -----
> = ruby(name) vs rubygems(name) =

Here is one important reason why Gems should not provide ruby(name):
The ruby(name) provides are supposed to be provided by the libraries, that are meant to be directly loadable with "require 'name'" even without Rubygems library. The Rubygems are loaded by default in Ruby 1.9.3, but the users may choose not to load them by passing "--disable-gems" option to the interpreter (either directly or via environment variable RUBYOPT).
For a user, who turns of his Rubygems, a packaged Gem providing ruby(name) wouldn't load, while some other non-gem package providing ruby(name) would load, which is obviously a puzzling behaviour.

Therefore, we should distinct these two cases for libraries, that are:
1) Loadable without Rubygems - these should provide ruby(name)
2) Loadable with Rubygems - these should provide rubygem(name)

--
Regards,
Bohuslav "Slavek" Kabrda.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2012, 01:53 PM
Rex Dieter
 
Default New packaging guidelines for Ruby

On 02/28/2012 05:39 AM, Vít Ondruch wrote:


Yes, Ruby SIG is still against it, since there is known just one gem ATM
which needs such treatment. Now I list several pros/cons:

Pros:
* It would allow ruby packages to follow the same steps as other packages.

Cons:
* More overhead for maintainers.
* More confusion for new-commers, since this approach is not know in
Ruby community and there is no best way how to achieve it.


If this notion of building from source is not known in the ruby
community, I'd highly recommend everyone (fpc, the ruby sig, etc...)
help make them aware of how important that is.


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

Dne 28.2.2012 15:53, Rex Dieter napsal(a):

On 02/28/2012 05:39 AM, Vít Ondruch wrote:


Yes, Ruby SIG is still against it, since there is known just one gem ATM
which needs such treatment. Now I list several pros/cons:

Pros:
* It would allow ruby packages to follow the same steps as other
packages.


Cons:
* More overhead for maintainers.
* More confusion for new-commers, since this approach is not know in
Ruby community and there is no best way how to achieve it.


If this notion of building from source is not known in the ruby
community, I'd highly recommend everyone (fpc, the ruby sig, etc...)
help make them aware of how important that is.


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. It is like trying to rebuild RPM with some
applied patch from RPM (yes, I am not speaking about SRPM but about RPM
and that is not mistake). How will you do it? Yes, the RPM contains the
same metadata as there were in original spec + SRPM but how will you
reconstruct them? Would you suggest somebody to use this approach?




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

On 02/28/2012 09:29 AM, Vít Ondruch wrote:


Pleas do not be mistaken. We are not speaking about building gems from
sources.


OK, so... is there some other better way to do it then? Please do
suggest any better alternative if you do.


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

Dne 28.2.2012 16:59, Rex Dieter napsal(a):

On 02/28/2012 09:29 AM, Vít Ondruch wrote:


Pleas do not be mistaken. We are not speaking about building gems from
sources.


OK, so... is there some other better way to do it then? Please do
suggest any better alternative if you do.


Better way is not doing it. Only in exceptional cases. And the case
happened just once as far as I know (and I did rebuild of all gems in
Fedora, so I should know).


This was the original guidelines proposal [1] which builds upon
experiences with previous guidelines and extend/fixed them where it was
appropriate. I found it very sensitive, where mandatory gem rebuild is
definitely not.



Vit



[1]
https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&oldid=270494#Applying_Patches




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


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

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

Dne 28.2.2012 16:59, Rex Dieter napsal(a):

On 02/28/2012 09:29 AM, Vít Ondruch wrote:


Pleas do not be mistaken. We are not speaking about building gems from
sources.


OK, so... is there some other better way to do it then? Please do
suggest any better alternative if you do.


Better way is not doing it.


I guess we may have to agree to disagree then. Guidelines that allow
for not building from (preferred form) source is deal-breaker for me at
least.


-- rex
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-28-2012, 03:32 PM
Jon Ciesla
 
Default New packaging guidelines for Ruby

On Tue, Feb 28, 2012 at 10:27 AM, Rex Dieter <rdieter@math.unl.edu> wrote:
> On 02/28/2012 10:13 AM, Vít Ondruch wrote:
>>
>> Dne 28.2.2012 16:59, Rex Dieter napsal(a):
>>>
>>> On 02/28/2012 09:29 AM, Vít Ondruch wrote:
>>>>
>>>>
>>>> Pleas do not be mistaken. We are not speaking about building gems from
>>>> sources.
>>>
>>>
>>> OK, so... is there some other better way to do it then? Please do
>>> suggest any better alternative if you do.
>>
>>
>> Better way is not doing it.
>
>
> I guess we may have to agree to disagree then. *Guidelines that allow for
> not building from (preferred form) source is deal-breaker for me at least.

Agreed. We have to rebuild Java jars, or not include them, no matter
how uncomfortable COUGH*gallery2*COUGH. I don't see why another
language should be any different.

-J

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



--
in your fear, seek only peace
in your fear, seek only love

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

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

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

Dne 28.2.2012 16:59, Rex Dieter napsal(a):

On 02/28/2012 09:29 AM, Vít Ondruch wrote:


Pleas do not be mistaken. We are not speaking about building gems from
sources.


OK, so... is there some other better way to do it then? Please do
suggest any better alternative if you do.


Better way is not doing it.


I guess we may have to agree to disagree then. Guidelines that allow
for not building from (preferred form) source is deal-breaker for me
at least.


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?



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

Dne 28.2.2012 17:32, Jon Ciesla napsal(a):

On Tue, Feb 28, 2012 at 10:27 AM, Rex Dieter<rdieter@math.unl.edu> wrote:

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

Dne 28.2.2012 16:59, Rex Dieter napsal(a):

On 02/28/2012 09:29 AM, Vít Ondruch wrote:


Pleas do not be mistaken. We are not speaking about building gems from
sources.


OK, so... is there some other better way to do it then? Please do
suggest any better alternative if you do.


Better way is not doing it.


I guess we may have to agree to disagree then. Guidelines that allow for
not building from (preferred form) source is deal-breaker for me at least.

Agreed. We have to rebuild Java jars, or not include them, no matter
how uncomfortable COUGH*gallery2*COUGH. I don't see why another
language should be any different.


It is different, because we do not provide any .gem package at the end.
.gems and .jars are something completely different. May be it is good
time to take a look on some rubygem's spec file.


Vit




-J


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





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

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
 

Thread Tools




All times are GMT. The time now is 08:31 AM.

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