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 03-05-2012, 05:50 AM
Bohuslav Kabrda
 
Default New packaging guidelines for Ruby

----- Original Message -----
> On Fri, Mar 02, 2012 at 12:42:26AM -0500, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> > > On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda
> > > <bkabrda@redhat.com>
> > > wrote:
> > > > ----- 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.
> > > >
> > > If the guidelines are to assume that people are going to be
> > > passing
> > > --disable-gems then they must require that non-gem subpackages
> > > exist
> > > for all gems. When a packager packages something that requires
> > > other
> > > ruby libraries they *must* inspect the code to see whether the
> > > code
> > > requires the gem or non-gem form. Otherwise, libraries,
> > > applications,
> > > and scripts will break when the user runs with the --disable-gems
> > > option.
> > >
> > > However, the argument that non-gem is legacy behaviour and should
> > > no
> > > longer be represented in packaging has been made. After looking
> > > at
> > > how rubygems have become such an integral part of the ruby
> > > ecosystem,
> > > this seems reasonable to me but it does not just mean that the
> > > non-gem
> > > subpackages have been simplified away. It also means that the
> > > Provides and Requires situation has been simplified as well. If
> > > you
> > > want to keep the ruby()/rubygem() Provides split because people
> > > may
> > > run ruby with "--disable-gems" then we need to make non-gem
> > > subpackages mandatory as well.
> > >
> > > -Toshio
> >
> > A simple question: why would we mandate creating non-gem
> > subpackages? If the developer uses --disable-gems, then he knows
> > he won't be able to require any gems. He may even base his code on
> > it:
> >
> > begin
> > require 'mocha'
> > rescue LoadError
> > Mocha = nil
> > end
> >
> > if Mocha then
> > # ...
> > else
> > # ...
> > end
> >
> > I believe that this simple piece of code says it all. The developer
> > may be doing something _based on the fact that rubygems are/are
> > not loaded_. Therefore creating non-gem subpackages should be
> > forbidden. Please note, that --disable-gems can be used, for
> > example, for use-cases where hundreds of ruby interpreters run in
> > parallel (not requiring rubygems can make things significantly
> > faster in this case), so I'm not just making all this up.
> >

Hi Toshio,
I believe you didn't get my point, I'll try to explain it differently:
You have a Ruby developer that is developing on some platform (which might not be Fedora) and as Ruby developers do, he uses Rubygems (installed by gem install command) and non-Gem libraries. Let's say that the Gem is rubygem-mocha and the non-gem package is ruby-bsearch. He installs mocha with "gem install mocha" and installs ruby-bsearch as administrator somewhere under %{ruby_sitelibdir}. If he runs the mentioned code with --disable-gems, he is counting on mocha not to be requireable => therefore raise the LoadError, which he catches. In this case, he still knows that he can require ruby-bsearch, as it is requireable without Rubygems. So the application runs and does some very fast stuff, because it's programmed that way. If the application is run with Rubygems, mocha is requireable and application does something different, which takes more time to do.
Now imagine a situation, that this developer deploys his application to Fedora, where local adminstrator has installed non-Gem subpackage of mocha. All of a sudden, the application doesn't run properly, because mocha is requireable even with --disable-gems. This is why non-Gem subpackages are bad and we shouldn't create them: There is nothing like this in the Ruby world, Ruby developers simply don't need it, will never use it and it may even seriously break their applications.
Please note, that ruby-bsearch has Provides: ruby(bsearch), as it is requireable with --disable-gems and mocha has Provides: rubygem(mocha) as it is requireable only with Rubygems, which makes perfect sense.

> If the developer codes something like that then a theoretical
> packaging of
> the code does not need to have a Requires: ruby(mocha) either. So
> this
> example doesn't show that Requires: ruby(mocha) or Requires:
> rubygem(mocha)
> would have any effect.
>
> Here's some examples of why I think that the Requires/Provides and
> the
> subpackages go hand in hand:
>
> (1)
> * My script has a "require 'mocha'" which, in Fedora is the packaged
> non-gem
> * mocha has a "require 'latte'" which, in Fedora is only packaged as
> a gem.
> ruby-mocha therefore has Require: rubygem(latte)
>
> If I run my script with --disable-gem my script will fail even though
> mocha
> was packaged as a non-gem and knew to Require the rubygem version of
> latte..
>

And this is precisely my point. It shows how creating and having non-Gem subpackages installed may break code - a code which relies on mocha not being requireable.

> (2)
> * My script has a "require 'mocha'".
> * mocha has a "require 'latte'" which in Fedora is only packaged as a
> gem.
> * The ruby-mocha package has Require: ruby(latte) since someone could
> attempt to run mocha with --disable-gems. Since there's no
> ruby(latte)
> Provides, ruby-mocha will either not pass review or fail to yum
> install on
> user's systems.
>

This shows even further, how non-Gem subpackages are not only dangerous, but also unnecessary load for the packagers.

> (3)
> * The web application better-cms is packaged in Fedora. It Requires:
> rubygem(latte) because it uses "require 'latte'"
> * I install that application on my server.
> * Because I want to make things faster, I try to run it with
> --disable-gems.
> * It fails because latte cannot be found if rubygems are not loaded.
>

The developer of the better-cms knows, that if his application is run with --disable-gems, it will not work. So he may tell his users "never do this, it's not supported" or he just finds non-Gem libraries, that he can use and use them. There isn't a single person in the Ruby world that I know, who would be using something like non-Gem subpackages. They are non-standard and dangerous and as I have shown, they can break your code. So why do you want to create them?

> In all of these cases a strict Require on whether the package needs
> the gem
> or non-gem version does not have an effect on whether the code in
> question
> will run -- it fails in all instances. In all cases, having a
> non-gem
> version of the gem libraries is one way to solve the problem. In all
> instances, deciding that rubygems must be loaded would also solve the
> problem.
>

Nope. The code in question will not run properly only in the case that the non-Gem subpackage is installed. Otherwise, it will work just fine and the way it was supposed to run. Moreover, the Provides: ruby(bsearch) and rubygem(mocha) make sense, since the first provide says, that the bsearch library is required with --disable-gems, while mocha is not.

> -Toshio

--
Regards,
Bohuslav "Slavek" Kabrda.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-05-2012, 02:05 PM
Toshio Kuratomi
 
Default New packaging guidelines for Ruby

On Mon, Mar 05, 2012 at 01:50:04AM -0500, Bohuslav Kabrda wrote:
> ----- Original Message -----
> > On Fri, Mar 02, 2012 at 12:42:26AM -0500, Bohuslav Kabrda wrote:
> > > ----- Original Message -----
> > > > On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda
> > > > <bkabrda@redhat.com>
> > > > wrote:
> > > > > ----- 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.
> > > > >
> > > > If the guidelines are to assume that people are going to be
> > > > passing
> > > > --disable-gems then they must require that non-gem subpackages
> > > > exist
> > > > for all gems. When a packager packages something that requires
> > > > other
> > > > ruby libraries they *must* inspect the code to see whether the
> > > > code
> > > > requires the gem or non-gem form. Otherwise, libraries,
> > > > applications,
> > > > and scripts will break when the user runs with the --disable-gems
> > > > option.
> > > >
> > > > However, the argument that non-gem is legacy behaviour and should
> > > > no
> > > > longer be represented in packaging has been made. After looking
> > > > at
> > > > how rubygems have become such an integral part of the ruby
> > > > ecosystem,
> > > > this seems reasonable to me but it does not just mean that the
> > > > non-gem
> > > > subpackages have been simplified away. It also means that the
> > > > Provides and Requires situation has been simplified as well. If
> > > > you
> > > > want to keep the ruby()/rubygem() Provides split because people
> > > > may
> > > > run ruby with "--disable-gems" then we need to make non-gem
> > > > subpackages mandatory as well.
> > > >
> > > > -Toshio
> > >
> > > A simple question: why would we mandate creating non-gem
> > > subpackages? If the developer uses --disable-gems, then he knows
> > > he won't be able to require any gems. He may even base his code on
> > > it:
> > >
> > > begin
> > > require 'mocha'
> > > rescue LoadError
> > > Mocha = nil
> > > end
> > >
> > > if Mocha then
> > > # ...
> > > else
> > > # ...
> > > end
> > >
> > > I believe that this simple piece of code says it all. The developer
> > > may be doing something _based on the fact that rubygems are/are
> > > not loaded_. Therefore creating non-gem subpackages should be
> > > forbidden. Please note, that --disable-gems can be used, for
> > > example, for use-cases where hundreds of ruby interpreters run in
> > > parallel (not requiring rubygems can make things significantly
> > > faster in this case), so I'm not just making all this up.
> > >
>
> Hi Toshio,
> I believe you didn't get my point, I'll try to explain it differently:
> You have a Ruby developer that is developing on some platform (which might not be Fedora) and as Ruby developers do, he uses Rubygems (installed by gem install command) and non-Gem libraries. Let's say that the Gem is rubygem-mocha and the non-gem package is ruby-bsearch. He installs mocha with "gem install mocha" and installs ruby-bsearch as administrator somewhere under %{ruby_sitelibdir}. If he runs the mentioned code with --disable-gems, he is counting on mocha not to be requireable => therefore raise the LoadError, which he catches. In this case, he still knows that he can require ruby-bsearch, as it is requireable without Rubygems. So the application runs and does some very fast stuff, because it's programmed that way. If the application is run with Rubygems, mocha is requireable and application does something different, which takes more time to do.
> Now imagine a situation, that this developer deploys his application to Fedora, where local adminstrator has installed non-Gem subpackage of mocha. All of a sudden, the application doesn't run properly, because mocha is requireable even with --disable-gems. This is why non-Gem subpackages are bad and we shouldn't create them: There is nothing like this in the Ruby world, Ruby developers simply don't need it, will never use it and it may even seriously break their applications.
> Please note, that ruby-bsearch has Provides: ruby(bsearch), as it is requireable with --disable-gems and mocha has Provides: rubygem(mocha) as it is requireable only with Rubygems, which makes perfect sense.
>
What you're dealing with is broken upstream code.

If the code is broken if the Mocha library is loadable, then the upstream
should be fixed to not load mocha.

If the upstream wants to be runnable using mocha in some cases but not in
other, then it should be fixed to take an option to control that.

Your hypothetical upstream is trying to use the ruby interpreter
--disable-gems command line switch to do "something extra". But there can
be no assurance that that will do that extra thing. What if the next
version of bsearch is only packagd as a gem? What if the next version of
mocha only comes as a non-gem? What if the system administrator has the
gemdir for Mocha in their RUBYPATH? Code that relies on a library being
outside of the path in order to run correctly is buggy code.


For the rest of your comments, it's my turn to say, "I believe you didn't
get my point". Please go back and reread my scenarios and understand them.

-Toshio

> > If the developer codes something like that then a theoretical
> > packaging of
> > the code does not need to have a Requires: ruby(mocha) either. So
> > this
> > example doesn't show that Requires: ruby(mocha) or Requires:
> > rubygem(mocha)
> > would have any effect.
> >
> > Here's some examples of why I think that the Requires/Provides and
> > the
> > subpackages go hand in hand:
> >
> > (1)
> > * My script has a "require 'mocha'" which, in Fedora is the packaged
> > non-gem
> > * mocha has a "require 'latte'" which, in Fedora is only packaged as
> > a gem.
> > ruby-mocha therefore has Require: rubygem(latte)
> >
> > If I run my script with --disable-gem my script will fail even though
> > mocha
> > was packaged as a non-gem and knew to Require the rubygem version of
> > latte..
> >
>
> And this is precisely my point. It shows how creating and having non-Gem subpackages installed may break code - a code which relies on mocha not being requireable.
>
> > (2)
> > * My script has a "require 'mocha'".
> > * mocha has a "require 'latte'" which in Fedora is only packaged as a
> > gem.
> > * The ruby-mocha package has Require: ruby(latte) since someone could
> > attempt to run mocha with --disable-gems. Since there's no
> > ruby(latte)
> > Provides, ruby-mocha will either not pass review or fail to yum
> > install on
> > user's systems.
> >
>
> This shows even further, how non-Gem subpackages are not only dangerous, but also unnecessary load for the packagers.
>
> > (3)
> > * The web application better-cms is packaged in Fedora. It Requires:
> > rubygem(latte) because it uses "require 'latte'"
> > * I install that application on my server.
> > * Because I want to make things faster, I try to run it with
> > --disable-gems.
> > * It fails because latte cannot be found if rubygems are not loaded.
> >
>
> The developer of the better-cms knows, that if his application is run with --disable-gems, it will not work. So he may tell his users "never do this, it's not supported" or he just finds non-Gem libraries, that he can use and use them. There isn't a single person in the Ruby world that I know, who would be using something like non-Gem subpackages. They are non-standard and dangerous and as I have shown, they can break your code. So why do you want to create them?
>
> > In all of these cases a strict Require on whether the package needs
> > the gem
> > or non-gem version does not have an effect on whether the code in
> > question
> > will run -- it fails in all instances. In all cases, having a
> > non-gem
> > version of the gem libraries is one way to solve the problem. In all
> > instances, deciding that rubygems must be loaded would also solve the
> > problem.
> >
>
> Nope. The code in question will not run properly only in the case that the non-Gem subpackage is installed. Otherwise, it will work just fine and the way it was supposed to run. Moreover, the Provides: ruby(bsearch) and rubygem(mocha) make sense, since the first provide says, that the bsearch library is required with --disable-gems, while mocha is not.
>
> > -Toshio
>
> --
> Regards,
> Bohuslav "Slavek" Kabrda.
> --
> 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 03-06-2012, 04:50 AM
Bohuslav Kabrda
 
Default New packaging guidelines for Ruby

----- Original Message -----
> On Mon, Mar 05, 2012 at 01:50:04AM -0500, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> > > On Fri, Mar 02, 2012 at 12:42:26AM -0500, Bohuslav Kabrda wrote:
> > > > ----- Original Message -----
> > > > > On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda
> > > > > <bkabrda@redhat.com>
> > > > > wrote:
> > > > > > ----- 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.
> > > > > >
> > > > > If the guidelines are to assume that people are going to be
> > > > > passing
> > > > > --disable-gems then they must require that non-gem
> > > > > subpackages
> > > > > exist
> > > > > for all gems. When a packager packages something that
> > > > > requires
> > > > > other
> > > > > ruby libraries they *must* inspect the code to see whether
> > > > > the
> > > > > code
> > > > > requires the gem or non-gem form. Otherwise, libraries,
> > > > > applications,
> > > > > and scripts will break when the user runs with the
> > > > > --disable-gems
> > > > > option.
> > > > >
> > > > > However, the argument that non-gem is legacy behaviour and
> > > > > should
> > > > > no
> > > > > longer be represented in packaging has been made. After
> > > > > looking
> > > > > at
> > > > > how rubygems have become such an integral part of the ruby
> > > > > ecosystem,
> > > > > this seems reasonable to me but it does not just mean that
> > > > > the
> > > > > non-gem
> > > > > subpackages have been simplified away. It also means that
> > > > > the
> > > > > Provides and Requires situation has been simplified as well.
> > > > > If
> > > > > you
> > > > > want to keep the ruby()/rubygem() Provides split because
> > > > > people
> > > > > may
> > > > > run ruby with "--disable-gems" then we need to make non-gem
> > > > > subpackages mandatory as well.
> > > > >
> > > > > -Toshio
> > > >
> > > > A simple question: why would we mandate creating non-gem
> > > > subpackages? If the developer uses --disable-gems, then he
> > > > knows
> > > > he won't be able to require any gems. He may even base his code
> > > > on
> > > > it:
> > > >
> > > > begin
> > > > require 'mocha'
> > > > rescue LoadError
> > > > Mocha = nil
> > > > end
> > > >
> > > > if Mocha then
> > > > # ...
> > > > else
> > > > # ...
> > > > end
> > > >
> > > > I believe that this simple piece of code says it all. The
> > > > developer
> > > > may be doing something _based on the fact that rubygems are/are
> > > > not loaded_. Therefore creating non-gem subpackages should be
> > > > forbidden. Please note, that --disable-gems can be used, for
> > > > example, for use-cases where hundreds of ruby interpreters run
> > > > in
> > > > parallel (not requiring rubygems can make things significantly
> > > > faster in this case), so I'm not just making all this up.
> > > >
> >
> > Hi Toshio,
> > I believe you didn't get my point, I'll try to explain it
> > differently:
> > You have a Ruby developer that is developing on some platform
> > (which might not be Fedora) and as Ruby developers do, he uses
> > Rubygems (installed by gem install command) and non-Gem libraries.
> > Let's say that the Gem is rubygem-mocha and the non-gem package is
> > ruby-bsearch. He installs mocha with "gem install mocha" and
> > installs ruby-bsearch as administrator somewhere under
> > %{ruby_sitelibdir}. If he runs the mentioned code with
> > --disable-gems, he is counting on mocha not to be requireable =>
> > therefore raise the LoadError, which he catches. In this case, he
> > still knows that he can require ruby-bsearch, as it is requireable
> > without Rubygems. So the application runs and does some very fast
> > stuff, because it's programmed that way. If the application is run
> > with Rubygems, mocha is requireable and application does something
> > different, which takes more time to do.
> > Now imagine a situation, that this developer deploys his
> > application to Fedora, where local adminstrator has installed
> > non-Gem subpackage of mocha. All of a sudden, the application
> > doesn't run properly, because mocha is requireable even with
> > --disable-gems. This is why non-Gem subpackages are bad and we
> > shouldn't create them: There is nothing like this in the Ruby
> > world, Ruby developers simply don't need it, will never use it and
> > it may even seriously break their applications.
> > Please note, that ruby-bsearch has Provides: ruby(bsearch), as it
> > is requireable with --disable-gems and mocha has Provides:
> > rubygem(mocha) as it is requireable only with Rubygems, which
> > makes perfect sense.
> >
> What you're dealing with is broken upstream code.
>

Nope. It may look broken to you, but it is not broken in the Ruby world. The only thing we can achieve by adding non-gem subpackages is breaking something, that is coded right. Is that really what we want?

> If the code is broken if the Mocha library is loadable, then the
> upstream
> should be fixed to not load mocha.
>

The idea of the code is trying to load a library that may or may not load and do something based on it. There is nothing wrong with that.

> If the upstream wants to be runnable using mocha in some cases but
> not in
> other, then it should be fixed to take an option to control that.
>
> Your hypothetical upstream is trying to use the ruby interpreter
> --disable-gems command line switch to do "something extra". But
> there can
> be no assurance that that will do that extra thing. What if the next
> version of bsearch is only packagd as a gem? What if the next
> version of
> mocha only comes as a non-gem? What if the system administrator has
> the
> gemdir for Mocha in their RUBYPATH? Code that relies on a library
> being
> outside of the path in order to run correctly is buggy code.
>

If next version of bsearch is only packaged as a gem, then we will have both ruby-bsearch and rubygem-bsearch (and please note, that the first one will provide ruby(bsearch) and the second one rubygem(bsearch) - do you see the difference now?), I see no problem with that. BUT, the developer still relies on the non-gem ruby-bsearch version and wants to use this one, not the gemified one, which might have changed. If he will want to depend on rubygem-bsearch, than he will change it for the new version and cope with it somehow. In the most unlikely scenario, where the next version of mocha comes out as non-gem library, the developer will obviously have to switch to something else. But you need to understand that switching from gem to non-gem in Ruby world is as likely as getting killed by falling piano.

>
> For the rest of your comments, it's my turn to say, "I believe you
> didn't
> get my point". Please go back and reread my scenarios and understand
> them.
>

I reread them, didn't get your point again. Could you please be more obvious and tell me what I didn't get?

> -Toshio
>
> > > If the developer codes something like that then a theoretical
> > > packaging of
> > > the code does not need to have a Requires: ruby(mocha) either.
> > > So
> > > this
> > > example doesn't show that Requires: ruby(mocha) or Requires:
> > > rubygem(mocha)
> > > would have any effect.
> > >
> > > Here's some examples of why I think that the Requires/Provides
> > > and
> > > the
> > > subpackages go hand in hand:
> > >
> > > (1)
> > > * My script has a "require 'mocha'" which, in Fedora is the
> > > packaged
> > > non-gem
> > > * mocha has a "require 'latte'" which, in Fedora is only packaged
> > > as
> > > a gem.
> > > ruby-mocha therefore has Require: rubygem(latte)
> > >
> > > If I run my script with --disable-gem my script will fail even
> > > though
> > > mocha
> > > was packaged as a non-gem and knew to Require the rubygem version
> > > of
> > > latte..
> > >
> >
> > And this is precisely my point. It shows how creating and having
> > non-Gem subpackages installed may break code - a code which relies
> > on mocha not being requireable.
> >
> > > (2)
> > > * My script has a "require 'mocha'".
> > > * mocha has a "require 'latte'" which in Fedora is only packaged
> > > as a
> > > gem.
> > > * The ruby-mocha package has Require: ruby(latte) since someone
> > > could
> > > attempt to run mocha with --disable-gems. Since there's no
> > > ruby(latte)
> > > Provides, ruby-mocha will either not pass review or fail to yum
> > > install on
> > > user's systems.
> > >
> >
> > This shows even further, how non-Gem subpackages are not only
> > dangerous, but also unnecessary load for the packagers.
> >
> > > (3)
> > > * The web application better-cms is packaged in Fedora. It
> > > Requires:
> > > rubygem(latte) because it uses "require 'latte'"
> > > * I install that application on my server.
> > > * Because I want to make things faster, I try to run it with
> > > --disable-gems.
> > > * It fails because latte cannot be found if rubygems are not
> > > loaded.
> > >
> >
> > The developer of the better-cms knows, that if his application is
> > run with --disable-gems, it will not work. So he may tell his
> > users "never do this, it's not supported" or he just finds non-Gem
> > libraries, that he can use and use them. There isn't a single
> > person in the Ruby world that I know, who would be using something
> > like non-Gem subpackages. They are non-standard and dangerous and
> > as I have shown, they can break your code. So why do you want to
> > create them?
> >
> > > In all of these cases a strict Require on whether the package
> > > needs
> > > the gem
> > > or non-gem version does not have an effect on whether the code in
> > > question
> > > will run -- it fails in all instances. In all cases, having a
> > > non-gem
> > > version of the gem libraries is one way to solve the problem. In
> > > all
> > > instances, deciding that rubygems must be loaded would also solve
> > > the
> > > problem.
> > >
> >
> > Nope. The code in question will not run properly only in the case
> > that the non-Gem subpackage is installed. Otherwise, it will work
> > just fine and the way it was supposed to run. Moreover, the
> > Provides: ruby(bsearch) and rubygem(mocha) make sense, since the
> > first provide says, that the bsearch library is required with
> > --disable-gems, while mocha is not.
> >
> > > -Toshio
> >
> > --
> > Regards,
> > Bohuslav "Slavek" Kabrda.
> > --
> > 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

--
Regards,
Bohuslav "Slavek" Kabrda.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-06-2012, 02:27 PM
Marcela Mašláňová
 
Default New packaging guidelines for Ruby

Hello list,
could we start with the discussion about the packaging guidelines for
Ruby once again? The discussion is very long and I guess everyone is now
lost in too many details.

I'd like to propose going over the whole guidelines, from a paragraph to
a paragraph, so it is clear what is okay and what is not and why.
From previous emails it looks like the discussion stalled and arguments
are only repeated over and over.

I believe whole Ruby SIG agreed on the guidelines. Would it help if more
people from SIG participate in this debate? Or would it be more specific
examples helpful?

Ruby is not like Perl or Python. It has its own specific ways. Upstreams
are usually not happy, when distribution change those specifics too
much. Some packages are hard to package into rpm and we need to do some
hacks around, which bring more comfort to packagers.

Please take a break for few days in this discussion and start again.

Regards,
Marcela
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-06-2012, 03:25 PM
Toshio Kuratomi
 
Default New packaging guidelines for Ruby

On Tue, Mar 06, 2012 at 04:27:56PM +0100, Marcela Mašláňová wrote:
> Hello list,
> could we start with the discussion about the packaging guidelines for
> Ruby once again? The discussion is very long and I guess everyone is now
> lost in too many details.
>
> I'd like to propose going over the whole guidelines, from a paragraph to
> a paragraph, so it is clear what is okay and what is not and why.
> From previous emails it looks like the discussion stalled and arguments
> are only repeated over and over.
>
> I believe whole Ruby SIG agreed on the guidelines. Would it help if more
> people from SIG participate in this debate? Or would it be more specific
> examples helpful?
>
Specific examples of what's broken by the proposal I've advanced will help.

I'll have time to work on the guidelines after March 16th -- going to
a conference in the next few hours.

> Ruby is not like Perl or Python. It has its own specific ways. Upstreams
> are usually not happy, when distribution change those specifics too
> much. Some packages are hard to package into rpm and we need to do some
> hacks around, which bring more comfort to packagers.
>
The first statement you make here is not true. Ruby is like Python and Php
and Java and Perl and OCaml and etc in these ways. Upstream communities
always have their ways of doing things that don't mesh with how software
should be packaged in a Linux distro. It's the job of the packaging
committee, packagers, and package reviewers to make packages that follow
best practices for a distro while living within the constraints imposed by
upstream software's technology and systems.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-09-2012, 12:57 PM
Vt Ondruch
 
Default New packaging guidelines for Ruby

Dne 29.2.2012 17:53, Toshio Kuratomi napsal(a):

On Wed, Feb 29, 2012 at 06:43:14AM -0500, Mo Morsi wrote:





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.



As Vit points out, there is no way to implement #2 alone -- it must be
combined with some form of #3 otherwise you just can't patch C Extensions.
A hybrid approach, though, could debate when you decide to implement #3
instead of #2. (ie: all patching, or only when patching C extensions?)



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?



I've been thinking about this for a week and also waiting for people to
bring forth packages that would be broken by it to see if there's any actual
problems with the strategy. No packages beyond the original one which is
a bug from upstream has been presented. Without that sort of example, I'm
going to vote for #3.

#2 is more complex as people have to keep in mind two sets of instructions.
When a bug fix is needed, it will not be simple to apply it as you'd have to
change the whole structure of the spec file in order to apply the patch and
then revert those changes when the patch is no longer needed. The
temptation for the packager in that situation will be to not apply bug fixes
until after they've made it into an upstream gem release.

#2 does not fix the problem with rpmbuild --short-circuit.

#3 was compared in the ticket with requiring "Fedora users to always rebuild
each RPM locally, because there might be sometimes broken dependency or
other error." This is a wrong comparison. A packager's job is to deal with
broken dependencies and other errors, not a users. #3 requires packagers to
deal with these issues, not users.

I'm also seeing the argument made for #2 that it's less work because
a single command exists to do all the steps. Therefore we should use it.
This is not a compelling argument because the same can be said of other
build systems. For most python code, for instance:

%setup -n %{srcname}-%{version}
python setup.py install --root %{buildroot}

even "make install" is valid under this argument.

#3 is also (barring someone giving us examples where packages are actually
broken) only a small one-time cost. Changing the rubygem spec files that
are using the old guidelines to use the new guidelines. As stated earlier,
the FPC has always known that the Rubygem guidelines needed to be changed
but was unaware that the time had come when the old guidelines were no
longer needed (lutter hasn't been on the FPC for years). Since you're
proposing changes to the guidelines anyway, you can hardly complain about
a one-time cost. In terms of an ongoing cost, until you show that there's
a non-bug reason that unpacking the source and rebuilding the gem is wrong,
there's no extra cost in maintaining this that package maintainers shouldn't
be responsible for anyhow.



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.



I'll try but you may need to pass my message through the ruby-sig
moderation queue.

-Toshio





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



Hi Toshio,



Today, in attempt to find some compromise solution, we tried to
"fix" RubyGems in a way, that would allow the following workflow:



%prep

%setup -q -c -T

mkdir -p .%{gem_dir}

gem install --local --install-dir .%{gem_dir}

*********** --force

*********** --skip-build

* * * * * * %{SOURCE0}



%build

pushd .%{gem_dir}/ext

./configure && make && make install

popd



%install

mkdir -p %{buildroot}%{gem_dir}

cp -a .%{gem_dir}/*

******* %{buildroot}%{gem_dir}/



The main differences are the "--skip-build" flag in %prep section
and the "./configure && make && make install" (or
some equivalent) in %build section. In the first moment, it looked
promising. Add the "--skip-build" flag should be easy as
conditionally execution the extension's build [1], i.e. almost one
line change. Unfortunately, it turned out that things are not as
easy as they seem on the first look.



First of all, the '"./configure && make && make
install" (or some equivalent)' is tricky, since there are currently
3 supported build methods by RubyGems



1) Traditional ./configure && make && make install"

2) The most widely used extconf.rb and make combo

3) Rake builder



It shouldn't be hard to support also other make alternatives. So
these 3 possibilities complicate the %build section enough.
Moreover, if you look on the implementation of the builders [2],
you'll see that the builders are patching the Makefiles on several
places, provide additional configuration options etc. There is no
good place where to cut-off the build on some lower layer.



In conclusion, this is dead end. The "--skip-build" option doesn't
look promising ATM unless the RubyGems would undergo some
significant changes.





Vit







[1]
https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L229

[2]
https://github.com/rubygems/rubygems/tree/master/lib/rubygems/ext



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 03-21-2012, 01:54 PM
Toshio Kuratomi
 
Default New packaging guidelines for Ruby

On Fri, Mar 2, 2012 at 12:40 AM, Vt Ondruch <vondruch@redhat.com> wrote:
>
>
> There are no problem with approach #3, since nobody uses it. I am not gonna
> to convert any of my packages just to prove you that you are wrong. Prove me
> that you are right, that rubygem-idn is the only problematic package and
> I'll believe you.
>
Since nobody else was willing to check how well #3 works, I've done so
by converting several packages that I picked at random from the first
packagedb page for packages beginning with rubygem-* (and
deltacloud-core which is given as an example in the guidelines so I
needed to make sure it worked):

http://toshio.fedorapeople.org/rubygems/

The common case is to add three lines, modify two others, and move
what gets done in %build vs %prep. I had to further modify one
package's spec file which had a find that was catching directories
when it should only be operating on files (added -type f). Thanks to
macros for gem_name and other package info, these changes don't even
vary from package to package. The one package that had patches applied
went from 11 lines of commands down to 9. Reorganizing that section
also made it obvious that the unittests were being installed in the
binary rpm under the old code, a problem that the new code did not
share. The application example also became simpler by two lines.

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

Thread Tools




All times are GMT. The time now is 02:51 PM.

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