Updated Guidelines Draft

[Bohuslav Kabrda]

Hi guys,
thank you all for your comments. I updated the guidelines draft to reflect them:
- BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
- The Gem versioned dependencies for R: and BR: were reformulated.
- Examples for packaging Gems with C extensions (did some rewriting in that section, too) and packaging Ruby applications (also fixed the header from h3 to h2 here :)) were added.
- Creation of non-Gem subpackages is no longer allowed.

It would be great if you could comment on the changes.

Regards,
Bohuslav.

[Mo Morsi]

On 01/02/2012 08:55 AM, Bohuslav Kabrda wrote:
> Hi guys,
> thank you all for your comments. I updated the guidelines draft to reflect them:

Again thanks for the new guidelines. Just a couple more comments inline 
below
> BR: ruby is now replaced with BR: ruby-devel for Ruby packages.

Possible duplication / discrepancy:

- In 'Ruby Packaging Guidelines':
"Ruby packages *must* require ruby-devel package at build time with a 
|BuildRequires: ruby-devel|, and *may* indicate the minimal ruby version 
they need for building."

- In 'Build Architecture and File Placement':
"All non-gem ruby packages *must* require ruby-devel package at build 
time with a |BuildRequires: ruby-devel|. "

Which should it be, 'all' ruby packages or just 'non-gem' ruby packages. 
Most likely the former, so for simplicity sake, the latter should be 
removed.
> The Gem versioned dependencies for R: and BR: were reformulated.

Looks good, again though, going w/ the bundler discussion we should also 
include a bit saying that the gem dependencies in the rpm spec, gemspec, 
and bundler Gemfile.lock (as well as any other package management system 
files tracking this) must be kept in sync.
> Examples for packaging Gems with C extensions (did some rewriting in that section, too)

Looks good
> and packaging Ruby applications (also fixed the header from h3 to h2 here :)) were added.

As far as the application example, is there a known example of one we 
could show that doesn't use rubygems. I imagine alot of end-user 
applications written in ruby do no use gems. I know the topic of 
shipping deltacloud in a non-gem form has been brought up on the 
deltacloud lists.
> Creation of non-Gem subpackages is no longer allowed.

Any thoughts on removing the rest of the contents of that section and 
just leave the caution. The extra stuff looks like it just creates 
clutter and can be retrieved from the wiki history if we wanted.
> It would be great if you could comment on the changes.

Thoughts? I can go in and make the proposed changes if that'd elaborate 
/ is desired.

-Mo

[Vít Ondruch]

Dne 4.1.2012 16:31, Mo Morsi napsal(a):
> On 01/02/2012 08:55 AM, Bohuslav Kabrda wrote:
> > Hi guys,
> > thank you all for your comments. I updated the guidelines draft to reflect them:
>
> Again thanks for the new guidelines. Just a couple more comments 
> inline below
> > BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
>
> Possible duplication / discrepancy:
> In 'Ruby Packaging Guidelines':
>
> "Ruby packages *must* require ruby-devel package at build time with a 
> |BuildRequires: ruby-devel|, and *may* indicate the minimal ruby 
> version they need for building."
> In 'Build Architecture and File Placement':
>
> "All non-gem ruby packages *must* require ruby-devel package at build 
> time with a |BuildRequires: ruby-devel|. "
>
> Which should it be, 'all' ruby packages or just 'non-gem' ruby 
> packages. Most likely the former, so for simplicity sake, the latter 
> should be removed.

The latter is correct, since gems requires rubygems-devel and that 
should be enough for gems.

However, reading the guidelines again, I am not happy with the 
structure. We have RubyGems section, but we don't have Non-gems section. 
The "Build Architecture and File Placement" should be probably 3rd level 
and we need some nice 2nd level caption. Any idea?
> > The Gem versioned dependencies for R: and BR: were reformulated.
>
> Looks good, again though, going w/ the bundler discussion we should 
> also include a bit saying that the gem dependencies in the rpm spec, 
> gemspec, and bundler Gemfile.lock (as well as any other package 
> management system files tracking this) must be kept in sync.
> > Examples for packaging Gems with C extensions (did some rewriting in that section, too)
>
> Looks good
> > and packaging Ruby applications (also fixed the header from h3 to h2 here :)) were added.
>
> As far as the application example, is there a known example of one we 
> could show that doesn't use rubygems. I imagine alot of end-user 
> applications written in ruby do no use gems. I know the topic of 
> shipping deltacloud in a non-gem form has been brought up on the 
> deltacloud lists.

Puppet always comes to me mind, but I am not sure that its .spec is the 
one I would like to use as an example :) But Bohuslav will have some tip 
I hope.
> > Creation of non-Gem subpackages is no longer allowed.
>
> Any thoughts on removing the rest of the contents of that section and 
> just leave the caution. The extra stuff looks like it just creates 
> clutter and can be retrieved from the wiki history if we wanted.
> > It would be great if you could comment on the changes.
>
> Thoughts? I can go in and make the proposed changes if that'd 
> elaborate / is desired.

Please feel free to update the draft wherever you think is suitable.

Vit
> -Mo
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

On 01/04/2012 11:19 AM, Vít Ondruch wrote:
> Dne 4.1.2012 16:31, Mo Morsi napsal(a):
> > On 01/02/2012 08:55 AM, Bohuslav Kabrda wrote:
> > > Hi guys,
> > > thank you all for your comments. I updated the guidelines draft to reflect them:
> >
> > Again thanks for the new guidelines. Just a couple more comments 
> > inline below
> > > BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
> >
> > Possible duplication / discrepancy:
> > In 'Ruby Packaging Guidelines':
> >
> > "Ruby packages *must* require ruby-devel package at build time with a 
> > |BuildRequires: ruby-devel|, and *may* indicate the minimal ruby 
> > version they need for building."
> > In 'Build Architecture and File Placement':
> >
> > "All non-gem ruby packages *must* require ruby-devel package at build 
> > time with a |BuildRequires: ruby-devel|. "
> >
> > Which should it be, 'all' ruby packages or just 'non-gem' ruby 
> > packages. Most likely the former, so for simplicity sake, the latter 
> > should be removed.
>
> The latter is correct, since gems requires rubygems-devel and that 
> should be enough for gems.

Hrm? Don't see a rubygems-devel subpackage in the rubygems spec, is this 
going to be updated as well to incorporate that?
> However, reading the guidelines again, I am not happy with the 
> structure. We have RubyGems section, but we don't have Non-gems 
> section. The "Build Architecture and File Placement" should be 
> probably 3rd level and we need some nice 2nd level caption. Any idea?

Good idea, not sure as to the 2nd level though

-Mo

[Vít Ondruch]

Dne 4.1.2012 23:02, Mo Morsi napsal(a):
> On 01/04/2012 11:19 AM, Vít Ondruch wrote:
> > Dne 4.1.2012 16:31, Mo Morsi napsal(a):
> > > On 01/02/2012 08:55 AM, Bohuslav Kabrda wrote:
> > > > Hi guys,
> > > > thank you all for your comments. I updated the guidelines draft to reflect them:
> > >
> > > Again thanks for the new guidelines. Just a couple more comments 
> > > inline below
> > > > BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
> > >
> > > Possible duplication / discrepancy:
> > > In 'Ruby Packaging Guidelines':
> > >
> > > "Ruby packages *must* require ruby-devel package at build time with 
> > > a |BuildRequires: ruby-devel|, and *may* indicate the minimal ruby 
> > > version they need for building."
> > > In 'Build Architecture and File Placement':
> > >
> > > "All non-gem ruby packages *must* require ruby-devel package at 
> > > build time with a |BuildRequires: ruby-devel|. "
> > >
> > > Which should it be, 'all' ruby packages or just 'non-gem' ruby 
> > > packages. Most likely the former, so for simplicity sake, the latter 
> > > should be removed.
> >
> > The latter is correct, since gems requires rubygems-devel and that 
> > should be enough for gems.
>
> Hrm? Don't see a rubygems-devel subpackage in the rubygems spec, is 
> this going to be updated as well to incorporate that?

RubyGems are currently build from ruby.spec. The independent 
rubygems.spec, which will allows to update RubyGems independently, is 
work in progress.

But if you check my testing repository, you'll see the rubygems-devel 
package already.

Vit

[Michael Stahnke]

On Wed, Jan 4, 2012 at 8:19 AM, Vít Ondruch  wrote:
> Dne 4.1.2012 16:31, Mo Morsi napsal(a):
>
> On 01/02/2012 08:55 AM, Bohuslav Kabrda wrote:
>
> Hi guys,
> thank you all for your comments. I updated the guidelines draft to reflect
> them:
>
> Again thanks for the new guidelines. Just a couple more comments inline
> below
> BR: ruby is now replaced with BR: ruby-devel for Ruby packages.
>
> Possible duplication / discrepancy:
> In 'Ruby Packaging Guidelines':
>
> "Ruby packages must require ruby-devel package at build time with a
> BuildRequires: ruby-devel, and may indicate the minimal ruby version they
> need for building."
> In 'Build Architecture and File Placement':
>
> "All non-gem ruby packages must require ruby-devel package at build time
> with a BuildRequires: ruby-devel. "
>
> Which should it be, 'all' ruby packages or just 'non-gem' ruby packages.
> Most likely the former, so for simplicity sake, the latter should be
> removed.
>
> The latter is correct, since gems requires rubygems-devel and that should be
> enough for gems.
>
> However, reading the guidelines again, I am not happy with the structure. We
> have RubyGems section, but we don't have Non-gems section. The "Build
> Architecture and File Placement" should be probably 3rd level and we need
> some nice 2nd level caption. Any idea?
> The Gem versioned dependencies for R: and BR: were reformulated.
>
> Looks good, again though, going w/ the bundler discussion we should also
> include a bit saying that the gem dependencies in the rpm spec, gemspec, and
> bundler Gemfile.lock (as well as any other package management system files
> tracking this) must be kept in sync.
> Examples for packaging Gems with C extensions (did some rewriting in that
>
> section, too)
>
> Looks good
>
> and packaging Ruby applications (also fixed the header from h3 to h2 here
> :)) were added.
>
> As far as the application example, is there a known example of one we could
> show that doesn't use rubygems. I imagine alot of end-user applications
> written in ruby do no use gems. I know the topic of shipping deltacloud in a
> non-gem form has been brought up on the deltacloud lists.
>
> Puppet always comes to me mind, but I am not sure that its .spec is the one
> I would like to use as an example :) But Bohuslav will have some tip I hope.

If there's something we can do to the Puppet Spec to make it better,
or more of an example please let me know.  The same spec is used
more-or-less on yum.puppetlabs.com also.
> Creation of non-Gem subpackages is no longer allowed.
>
> Any thoughts on removing the rest of the contents of that section and just
> leave the caution. The extra stuff looks like it just creates clutter and
> can be retrieved from the wiki history if we wanted.
>
> It would be great if you could comment on the changes.
>
> Thoughts? I can go in and make the proposed changes if that'd elaborate / is
> desired.
>
> Please feel free to update the draft wherever you think is suitable.
>
> Vit
>
> -Mo
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Michael Stahnke]

In looking at the guidelines it looks like

%gem_dir is /usr/share/gems

but gem_instdir is /usr/share/gems/gems/foo-1.0.0/

Is the gems/gems correct?

(This is copying in the macros verbatim from
https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Ruby_Applications)

[Bohuslav Kabrda]

Yes, this is correct - the /usr/share/gems directory contains more directories, like any directory that you install gems into - cache, docs, specification, gems.

----- Original Message -----
> In looking at the guidelines it looks like
>
> %gem_dir is /usr/share/gems
>
> but gem_instdir is /usr/share/gems/gems/foo-1.0.0/
>
> Is the gems/gems correct?
>
> (This is copying in the macros verbatim from
> https://fedoraproject.org/wiki/PackagingDrafts/Ruby#Ruby_Applications)
> _______________________________________________
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig