#2178 Set default module stream for ruby
Closed: Invalid a month ago by ignatenkobrain. Opened a month ago by jaruga.

Describe the issue

the ruby module doesn't have a default stream yet.
I'd like to set '2.6' as the default module stream.

When do you need this? (YYYY/MM/DD)

ASAP (2019/07/16).

When is this no longer needed or useful? (YYYY/MM/DD)

We need to upgrade the default stream when we release new modules/ruby version stream.

If we cannot complete your request, what is the impact?

This ticket comes from https://bugzilla.redhat.com/show_bug.cgi?id=1729150 .
At least the reporter is not happy if you cannot complete this request.

Related pull-request:
https://pagure.io/releng/fedora-module-defaults/pull-request/134

Thanks.


Given that we still can't use modules in non-modular buildroot and there are many problems with changing defaults, I'm -1 especially for component like Ruby.

What are the problems?
What do you mean for "component like Ruby"?

Can we keep the "default" Ruby in non-modular Fedora and only provide modules with alternate versions of it?

Hello, I am the reporter of the aforementioned bug and I am a member of Fedora QE assigned for modularity.

This is just a top of the iceberg, and I have been pushing this since Fedora 29, but it is not clear to me if modules are required to have defaults set. In the past, I approached some modularity people, like @sgallagh, @psabata, @asamalik, and from discussions with them I gained a notion, that modules with defaults set should be an example of good practice, unless they are explicitly meant not to be installed (for example when they only serve as dependency modules).

Currently, there are approx. 25 such modules on Fedora Rahwhide. I have opened bugs where I required the maintainers to fix it, or tell me that it is not set on purpose.

It is difficult for me to know which modules do not have defaults set because it is meant to be like that and which are just product of some error.

I can live with Ruby (or anything) without having the defaults set, but I need to know that this is correct.

Please, can you provide any info on that? Thanks.

Can we keep the "default" Ruby in non-modular Fedora and only provide modules with alternate versions of it?

No, problem from my side. I just want to know that this is what it should be. :D

If the Ruby module gets a default, what should happen if I dnf install ruby?

If the Ruby module gets a default, what should happen if I dnf install ruby?

That would install Ruby from the modular content.
I am repeating: I do not want to decide how Ruby is shipped in Fedora. I just want to check, that it is shipped correctly. :D

Given that the Ruby installed for users would not be the same Ruby used in Fedora buildroot, I'm -1 as well.

@lruzicka If we have modules without default streams, and dnf module install simply fails, I guess we should fix the UX and communicate: "There is no default stream, use the non-modular content from non-modular Fedora . Try: dnf install ruby"

@churchyard, yes, that would be nice .... and such discussions have already started, but then it somehow died without a real impact on how the UX deals with it.

But, it does not solve my situation, because I need someone to tell me: "Hey, I created the module without defaults, because I think it is correct". Then, I am going to add that module into my whitelist and never bother again until next release, when I am going to ask if the previous decision is still valid.

Does that seem reasonable?

If the Ruby module gets a default, what should happen if I dnf install ruby?

That would install Ruby from the modular content.

Oh that is not good behavior.
I want to keep current behavior to install rpms/ruby directly without modular, when do dnf install ruby.

If the Ruby module gets a default, what should happen if I dnf install ruby?

That would install Ruby from the modular content.

Oh that is not good behavior.
I want to keep current behavior to install rpms/ruby directly without modular, when do dnf install ruby.

I believe that. Than do not make the stream default and tell me that you do not intend to have that behaviour.

I believe that. Than do not make the stream default and tell me that you do not intend to have that behaviour.

Sure, now I tell you that we do not make the stream default for modules/ruby, and we do not intend to have the behavior to install module ruby when doing dnf install ruby.

I did not expect the default stream affected the behaviors for both dnf install ruby and dnf module install ruby. I expected the default stream of the module only affected for dnf module install ruby.

I did not expect the default stream affected the behaviors for both dnf install ruby and dnf module install ruby. I expected the default stream of the module only affected for dnf module install ruby.

Then you should not set default stream :) That is the only purpose of default streams.

I'm closing this ticket since this is actually not what you want…

Metadata Update from @ignatenkobrain:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

a month ago

Hello, I am the reporter of the aforementioned bug and I am a member of Fedora QE assigned for modularity.
This is just a top of the iceberg, and I have been pushing this since Fedora 29, but it is not clear to me if modules are required to have defaults set. In the past, I approached some modularity people, like @sgallagh, @psabata, @asamalik, and from discussions with them I gained a notion, that modules with defaults set should be an example of good practice, unless they are explicitly meant not to be installed (for example when they only serve as dependency modules).
Currently, there are approx. 25 such modules on Fedora Rahwhide. I have opened bugs where I required the maintainers to fix it, or tell me that it is not set on purpose.
It is difficult for me to know which modules do not have defaults set because it is meant to be like that and which are just product of some error.
I can live with Ruby (or anything) without having the defaults set, but I need to know that this is correct.
Please, can you provide any info on that? Thanks.

We've been over this several times, but maybe we need to have it recorded somewhere formally in the documentation. Our policy in Fedora should be that all modules must have an associated defaults document in https://pagure.io/releng/fedora-module-defaults

From QA's perspective, the lack of this document for a module should be treated as a bug. However, if this defaults document exists and it does not specify a default stream, then this should be treated as intentional.

Does that make sense?

Dne =C3=BAt 16. =C4=8Dvc 2019 19:09 u=C5=BEivatel Stephen Gallagher pagure= @pagure.io
napsal:

sgallagh added a new comment to an issue you are following:
``

We've been over this several times, but maybe we need to have it recorded
somewhere formally in the documentation.

Yes, it definitely needs to be documented, so that people know what to
expect.

Our policy in Fedora should be that all modules must have an associated

defaults document in https://pagure.io/releng/fedora-module-defaults

From QA's perspective, the lack of this document for a module should be
treated as a bug. However, if this defaults document exists and it does n=
ot
specify a default stream, then this should be treated as intentional.

Does that make sense?
``

Yes, that totally makes sense. Now, it is finally clear to me. Thanks.

@asamalik Can you please find the right place in the documentation to note this around the defaults? That the Fedora policy is that all modules must have a defaults object. QA should treat the lack of a default object as a bug. If it has a defaults object that does not specify a default stream, that should be taken to be intentional. QA should file bugs for the lack of a defaults object and for the the lack of default profiles for any available stream on a release.

Could somebody explain what it actually means the "default module stream". I can't understand from anywhere that it would related to "Given that we still can't use modules in non-modular buildroot and there are many problems with changing defaults" or especially to "Can we keep the "default" Ruby in non-modular Fedora and only provide modules with alternate versions of it?". It is definitely not obvious from the documentation [1].

Could somebody explain what it actually means the "default module stream".

In my understanding, when modules/ruby:2.6 is default stream, it is enabled as an initial condition like below "2.6 [e]".

On my Fedora 30,

$ dnf module list ruby
Fedora Modular 30 - x86_64 - Updates                           21 kB/s |  21 kB     00:01    
Fedora Modular 30 - x86_64 - Updates                          203 kB/s | 242 kB     00:01    
Fedora 30 - x86_64 - Updates                                   24 kB/s |  21 kB     00:00    
Fedora 30 - x86_64 - Updates                                  674 kB/s | 1.7 MB     00:02    
Last metadata expiration check: 0:00:01 ago on Wed 17 Jul 2019 12:45:22 PM CEST.
Fedora Modular 30 - x86_64
Name      Stream       Profiles      Summary                                                  
ruby      master       default       An interpreter of object-oriented scripting language     

Fedora Modular 30 - x86_64 - Updates
Name      Stream       Profiles      Summary                                                  
ruby      master       default       An interpreter of object-oriented scripting language     
ruby      2.5          default       An interpreter of object-oriented scripting language     
ruby      2.6 [e]      default       An interpreter of object-oriented scripting language     

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

As a result, when running dnf install ruby, ruby-2.6.3-120.module_f30+4422+f50e013d.x86_64 is installed instead of ruby-2.6.3-120.fc30.x86_64.

When running dnf module install ruby, dnf module install ruby:2.6 is executed.
If the default module is not set, dnf module install ruby shows only error message.

Right?

If the default module is not set, dnf module install ruby shows only error message.
Right?

Yes.

Login to comment on this ticket.

Metadata