Re: RHEL 9 and modularity
by Nicolas Mailhot
Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit :
> I see. I focused on having the stream information on RPM level. Then
> the
> answer is no, the package name does not contain the information.
>
> My idea was that DNF could discriminate the same-name package using
> the
> ModularityLabel tag instead of relying on modulemd documents
> delivered in the
> repository metadata.
One problem of having it a tag (which we do not even have in Fedora) is
that it requires rewriting dependency resolution logic at dnf level,
and a Tag does not come with all the dependency manipulation verbs we
have evolved over the years for Provides and Requires.
--
Nicolas Mailhot
3 years, 10 months
Re: RHEL 9 and modularity
by Nicolas Mailhot
Le mercredi 24 juin 2020 à 12:03 +0200, Nicolas Mailhot a écrit :
> Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit :
> > I see. I focused on having the stream information on RPM level.
> > Then
> > the
> > answer is no, the package name does not contain the information.
> >
> > My idea was that DNF could discriminate the same-name package using
> > the
> > ModularityLabel tag instead of relying on modulemd documents
> > delivered in the
> > repository metadata.
>
> One problem of having it a tag (which we do not even have in Fedora)
> is
> that it requires rewriting dependency resolution logic at dnf level,
> and a Tag does not come with all the dependency manipulation verbs we
> have evolved over the years for Provides and Requires.
That is what killed the group tag and comps groups as generic ways to
declare package grouping BTW.
RPM maintainers were long opposed to metapackages, but in the end
metapackages offer more packager flexibility, and appear as normal
objects in the dependency graph, meaning you can do things with them
you could never achieve with an out-of-graph Comps/Tag group.
--
Nicolas Mailhot
3 years, 10 months
Re: RHEL 9 and modularity
by Petr Pisar
On Wed, Jun 24, 2020 at 12:03:05PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 24 juin 2020 à 11:56 +0200, Petr Pisar a écrit :
> > I see. I focused on having the stream information on RPM level. Then the
> > answer is no, the package name does not contain the information.
> >
> > My idea was that DNF could discriminate the same-name package using the
> > ModularityLabel tag instead of relying on modulemd documents delivered in
> > the repository metadata.
>
> One problem of having it a tag (which we do not even have in Fedora)
I believe having it in Fedora is only a matter of changing MBS configuration.
> is that it requires rewriting dependency resolution logic at dnf level,
DNF has a steadfast idea that an upgrade path is only based on a package name.
Without changes in DNF, DNF will either switch a stream just because a package
from a concurrent stream has a higher version, or will complain that it cannot
upgrade to the lastest version. Neither of the options is a desired behavior.
Thus I believe that changing DNF is inevitable.
> and a Tag does not come with all the dependency manipulation verbs we
> have evolved over the years for Provides and Requires.
>
ModularityLabel designates an affilation to a stream. That can be reduced to
"Requires: module(name:stream)" or "Requires: module(name) = stream". I'm not
agaist abusing Requires for that purpose. But it alone won't fix the issue with
enforcing a presence of a stream I drafted above.
-- Petr
3 years, 10 months
Re: RHEL 9 and modularity
by Miro Hrončok
On 24. 06. 20 14:41, Vít Ondruch wrote:
> Having python27 and python36 modules is fail, because these should be
> 2.7 and 3.6 streams of python module.
Oh. We are so sorry for the failure. Could you please report is as a bug in RHEL
8 and explain why it is a problem?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 10 months
Re: RHEL 9 and modularity
by Vít Ondruch
Dne 24. 06. 20 v 15:47 Miro Hrončok napsal(a):
> On 24. 06. 20 14:41, Vít Ondruch wrote:
>> Having python27 and python36 modules is fail, because these should be
>> 2.7 and 3.6 streams of python module.
>
> Oh. We are so sorry for the failure. Could you please report is as a
> bug in RHEL 8 and explain why it is a problem?
>
If you have not stripped the context, it would be more obvious.
There is no philosophical (or design?) reason to not have Python 2.7 and
3.6 streams in one module. There are just technical reasons, such as
that you want to install them in parallel which is not possible.
Vít
3 years, 10 months
Re: RHEL 9 and modularity
by Nico Kadel-Garcia
On Wed, Jun 24, 2020 at 10:45 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>
>
> Dne 24. 06. 20 v 15:47 Miro Hrončok napsal(a):
> > On 24. 06. 20 14:41, Vít Ondruch wrote:
> >> Having python27 and python36 modules is fail, because these should be
> >> 2.7 and 3.6 streams of python module.
> >
> > Oh. We are so sorry for the failure. Could you please report is as a
> > bug in RHEL 8 and explain why it is a problem?
> >
>
> If you have not stripped the context, it would be more obvious.
>
> There is no philosophical (or design?) reason to not have Python 2.7 and
> 3.6 streams in one module. There are just technical reasons, such as
> that you want to install them in parallel which is not possible.
Not publishing unsupportable and inevitably compatible software which
relies on two entirely distinct versions of the same interpreter is a
pretty compelling set of philosophical and design reasons.
3 years, 10 months
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33
Self-Contained Change proposal
by Stephen Gallagher
On Fri, Jul 10, 2020 at 7:28 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
...
> As said in the modularity docs PR (but I cannot find it now, because pagure.io
> is down), I am not sure what is the outcome wrt default streams. Default streams
> are not allowed now. If this change proposal and the policy is approved, does it
> mean that:
>
> 1) default streams are still not allowed (and hence the default streams section
> of the policy is moot)
>
> 2) default streams are allowed (and hence it should be spelled out explicitly
> and this should be a system wide change proposal)
>
> 3) default streams are allowed in ELN, but not in non-ELN Fedora (and hence it
> should at least be said somewhere - in the policy or in the proposal)
>
> 4) something different?
...
I was on PTO last week, sorry for the late reply.
I phrased this policy in such a way that it can apply to any of those
cases. Use of *any* default in Fedora or ELN must be approved by FESCo
(with the option for FESCo to delegate that decision to the ELN SIG if
desired). Right now, FESCo's position on modular defaults in non-ELN
Fedora is "any such requests will be denied". The policy leaves it
open for FESCo to make an exception if they deem it appropriate. Does
that clear things up?
3 years, 9 months
Re: Modularity Improvements Objective
by Kevin Fenzi
On Fri, Jul 24, 2020 at 11:16:16AM -0400, Neal Gompa wrote:
>
> Unfortunately, MBS is maintained by a different team: the team that
> maintains Koji. I am unsure about what they're planning to do, but I
> hope they're going to do *something*.
To add history here, MBS was written by and maintained by a different
team until early this year, when it was handed off to the koji team.
Last I heard they were still trying to get up to speed on the codebase,
etc. It's not easy to take a codebase someone else has written and
maintained and take it over. ;(
I'm of course not speaking for them, and hopefully they will chime in
here with more info...
kevin
3 years, 9 months
Re: Proposed Modular Policy for Fedora ELN
by Petr Pisar
On Wed, Aug 05, 2020 at 10:50:59PM -0400, Stephen Gallagher wrote:
> On Wed, Aug 5, 2020 at 6:17 PM James Cassell <fedoraproject(a)cyberpear.com>
> wrote:
> >
> > On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote:
> > > * If a stream of a module has build-time-only components, all such
> > > components *MUST* be marked as `buildonly: True` in the module
> > > metadata to avoid shipping them to users and polluting their
> > > repository.
> > >
> >
> > Can these be directed to a disabled-by-default build-dep repo of some kind
> > for those trying to do local builds?
> >
>
> That's not really a policy question, but it's *possible* that we could
> do that as part of the compose. I don't see a lot of reason to do so,
> since a local MBS build will handle it for you and as we establish
> later on, the use of these should be a last resort, not a common
> practice.
>
These build-only components are handy for running tests after the build.
E.g. a non-build component has upstream tests. They are run at build-time, and
thus the module contains build-only components for performing the test. The
tests are also packaged into a subpackage and the subpackage is filtered from
the module. ("buildonly: true" is only a different form of "filter" modulemd
section.) Later a CI may want to install the subpackage and reproduce the
tests.
-- Petr
3 years, 9 months
