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

2020-04-13 Thread Lucas Kanashiro
Hi,

On 13/04/2020 09:05, Antonio Terceiro wrote:
> On Mon, Apr 13, 2020 at 01:03:47AM +0200, Daniel Leidert wrote:
>> 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?

It is indeed a good idea, I already faced a similar issue in the past.

> I think this is a good idea.
>
> Are you willing to do it? If yes just do it, or if not, please open a
> bug report so it doesn't get lost.

I am already adding some changes in src:ruby2.7 to better support riscv,
I can add the Provides suggested by Daniel.

Cheers!

-- 
Lucas Kanashiro




signature.asc
Description: OpenPGP digital signature


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

2020-04-13 Thread Antonio Terceiro
On Mon, Apr 13, 2020 at 01:03:47AM +0200, Daniel Leidert wrote:
> 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?

I think this is a good idea.

Are you willing to do it? If yes just do it, or if not, please open a
bug report so it doesn't get lost.


signature.asc
Description: PGP signature


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