Re: Should libruby2.x have Provides: ruby-foo (= x.y.z) for the gems it ships?

2020-04-12 Thread Georg Faerber
Hi Daniel, all,

On 20-04-13 01:03:47, Daniel Leidert wrote:
> What are your thoughts?

Sounds reasonable, and good!

Thanks,
cheers,
Georg



Should libruby2.x have Provides: ruby-foo (= x.y.z) for the gems it ships?

2020-04-12 Thread Daniel Leidert
Hi there,

the libruby2.x packages ship special versions of some gems. Also in Ruby 2.7
parts were split out into gems and we already packaged them separately. So the
gem is available from libruby2.7 and ruby-. But libruby actually provides
at least a version of the gem and might in some cases be sufficient enough to
fulfill a depency. IMHO the libruby2.7 package for example should have:

Provides: ruby-benchmark (= 0.1.0), ruby-bigdecimal (= 2.0.0), [..], ruby-rexml 
(= 3.2.3), [..], ruby-yaml (= 0.1.0), ruby-zlib (= 1.1.0)

IMHO the perl team does the same (e.g. check out perl-base) and it actually
seems rigth to me that we do this too.

So for example we wouldn't have to fiddle with ${ruby:Depends} in rubocop. A
dependency on ruby-rexml would then be fulfilled by either libruby2.7 or ruby-
rexml (which I'm currently packaging).

What are your thoughts?

Regards, Daniel


signature.asc
Description: This is a digitally signed message part


Re: parser vs ruby_parser gems

2020-04-12 Thread Pirate Praveen




On Fri, Mar 13, 2020 at 11:25 am, Antonio Terceiro 
 wrote:

On Fri, Mar 13, 2020 at 01:41:37PM +0530, Pirate Praveen wrote:



 On 2020, മാർച്ച് 12 7:58:34 PM IST, Antonio Terceiro 
 wrote:

 >On Thu, Mar 12, 2020 at 07:05:42PM +0530, Pirate Praveen wrote:
 >> On 2020, മാർച്ച് 12 12:28:52 AM IST, Kiran 
Skunjumon

 > wrote:
 >> >their is two gem parser and ruby_parser.
 >> >In debian ruby_parser is packaged under ruby-parser instead of
 >> >ruby-ruby-parser.
 >> >parser is a dependency of unparser .
 >> >now i am stuck
 >>
 >> I think we can use the github username (like we did earlier and a
 >common practice for forks) to create a unique name for the new 
package.

 >So we can package parser gem as ruby-whitequark-parser.
 >
 >In this case it's not really a fork, it's a problem with our naming
 >convention.  We should stop making exceptions for gems whose names
 >start
 >with "ruby[-_]*, and make ruby_foo become ruby-ruby-foo, not just
 >ruby-foo.
 >
 >IMO it would be better to fix the name of existing package now 
instead

 >of postponing this. It would be
 >
 >- rename ruby-parser to ruby-ruby-parser
 >
 >- introduce parser as ruby-parser, adding Breaks: against versions 
of

 >  the packages that currently dependend on ruby-parser wanting the
 >  "ruby_parser" gem.
 >
 >  $ reverse-depends ruby-parser
 >  Reverse-Depends
 >  * gitlab
 >  * obs-api
 >  * roodi
 >  * ruby-html2haml
 >  * ruby-ruby2ruby
 >
 > Those packages would need to be adjusted to depend on 
ruby-ruby-parser

 >  instead.

 OK I'll start with renaming ruby-parser to ruby-ruby-parser and 
follow the steps once it is accepted in the archive.


cool, thanks

FWIW yesterday I committed a change to gem2deb to drop this exception
for "ruby" in gem names: https://deb.li/41zI


Great. I have uploaded fixed versions of all reverse dependencies 
except obs-api. For obs-api I filed #956504 as there were many changes 
in master I'm not sure if it is ready for upload.


ruby-ruby-parser has a Breaks and Replaces which forces updating the 
packages that depends on older ruby-parser when ruby-ruby-parser gets 
installed.