Re: RHEL 9 and modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 23. 06. 20 v 14:02 Josh Boyer napsal(a):
> On Tue, Jun 23, 2020 at 7:56 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>> On 23. 06. 20 13:43, Josh Boyer wrote:
>>> On Tue, Jun 23, 2020 at 7:36 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>>>> On 23. 06. 20 13:29, Josh Boyer wrote:
>>>>>>     (It*may*  be possible to automatize this, but not as easily as with
>>>>>>     singular packages. And considering that non-modularized packages
>>>>>>     need to be handled too, there will be at least two paths.)
>>>>>>
>>>>>> - (hypothetically) if we have default modules in eln, and work is done
>>>>>>     in those modules and skipping rawhide (for example by not building the
>>>>>>     packages in rawhide), we have an unpleasant situation where eln and
>>>>>>     rawhide diverge.
>>>>> This is a very tenuous strawman.  You could also run into a case where
>>>>> ELN forbids modules or default module streams and the maintainers
>>>>> simply choose not to maintain anything in Fedora at all.  That's far
>>>>> worse than divergence in my opinion.
>>>> When ELN was proposed and discussed, separate eln branches were proposed by
>>>> several Fedora and RHEL maintainers. It was dismissed, and it was said
>>>> repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that
>>>> requirement has changed.
>>> Divergence where?  At the source level?  Why would the existence of a
>>> default module in ELN cause divergence at the source level?  It
>>> wouldn't.  The rawhide sources would be used for the module build in
>>> ELN.
>> I ma concerned about divergence at source level. Modules in Fedora are built
>> from stream branches. Rawhide content is built from the "master" branch. This is
>> the first time I've heard that rawhide sources would be used for the module
>> build in ELN and it certainly makes the entire thing more appealing. I've
>> already asked about this in:
>>
>> https://pagure.io/fesco/issue/2390#comment-659188
> Hmm.  I have introduced confusion.  My apologies for that, and let me rephrase.
>
> First, I was talking about the sources themselves, not necessarily the
> branches.  If you look at a single package, its source doesn't really
> change when it's built as a stand-alone RPM, or a modular RPM.  It's
> just a package.  Therefore, there isn't divergence at the source
> level.  If the same version of the source is used in rawhide and ELN,
> then I don't see divergence.


This would be true if module was supposed to support only single Fedora
version. If module supports multiple versions, this cannot be further
from reality. And in the context of ELN, this is the later case.


Vít


>
> Secondly, I did not mean to imply there were concrete plans to build
> modules from the rawhide branch in Fedora.  I should have said
> "could", not "would".  However, if that's an approach that makes
> things better in some ways then perhaps it should be looked at in
> earnest as a compromise?
>
> josh
>
>>> If you mean at the binary level, then I have no idea how anyone
>>> possibly thinks ELN and Rawhide are the same because ELN is built with
>>> entirely different flags, settings, etc.
>> No, I don't.
>>
>>>>> Fortunately, I think neither are
>>>>> actually likely and this part of the conversation seems like it's
>>>>> pointless to debate.
>>>> This has happened in the past when Fedora had default modular streams. Whether
>>>> likely or not to repeat, we have experience with the problem, so the discussion
>>>> is not pointless at all.
>>> You seem to be concerned less about divergence and more about
>>> abandonment of packages in Fedora, at least in ways counter to how the
>>> default distribution is built.  You could come up with some guidelines
>>> on usage of ELN modules that require existing content to be maintained
>>> as it is in Fedora if that's what you want to ensure.  It's onerous
>>> and causes extra work, but allows people to do their work in the open.
>>> However, if you prevent that from happening entirely, you run the risk
>>> of them abandoning the packages entirely which is counter to your goal
>>> (I think).
>> I can totally support that. Thanks.
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux