On Wed, Nov 13, 2019 at 12:00 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 12. 11. 19 18:25, Aleksandra Fedorova wrote:
> On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 12. 11. 19 17:02, Aleksandra Fedorova wrote:
>>> Again, no one forces you or any other packager to use modularity
>>> tooling right now.
>>> As Fedora developer you have a choice to join the effort, bring your
>>> input and use cases, try and test (and revert if it doesn't work) or
>>> you can stay away from it and keep using same tools as before.
>> Unfortunately, this is not true. It is not possible to ignore modularity, if
>> dependencies are modularized. It is not possible to ignore modularity, if the
>> dependents are modularized. It is not possible to ignore modularity, if the
>> packages I wish to use are modularized.
>> I wish Fedora packagers and users cold "stay away". But that is
>> possible. My proposal to keep all defaults as non-modular packages would make
>> exactly so.
> Ursa Prime effort achieves the same goal. It removes the "viral" part
> of Modularity I think.
Ursa Prime effort puts module sin the buildroot. I'm still waiting to hear about
how it deals with conflicts with non-modular packages, how it works with mock
and what it actually does.
Not getting those answers was one of the many reasons I voted against the change
proposal. Yet every time I point out my reasons, people seem to only see the one
that says I think we should not have default streams at all. And I kinda get
that, but the other reasons are equally important.
Before I get the answers, I cannot agree or disagree with you, because I don't
know what it achieves or not.
However, and I speculate here, IMHO it only gives me the ability to buildrequire
a modular (meeting certain criteria) package from a non-modular package. It
doesn't give me a "stay away" card. I still need to deal with modules if
package depends on them or if they depend on my package.
As an example, if I choose to depend on module and the modular maintainer
chooses not to care about the module, it gets broken or insecure and I have no
way to fix it other than learning how to do modules.
Yes, the "stay away" wouldn't work in case you would like to
co-maintain or unorphan the modularized package.
Exactly the same way as "stay away" won't work for automatic
BuildRequires generator feature, which we voted for in this cycle.
If you are not familiar with the concept, then to adopt the package,
which is using it, you are going to need to learn the concept first.
And (at least for me) the modules metadata file which describes group
of _standard_ RPM packages is a much easier concept to grasp.
As an example, I've asked months ago what should I do with
modules when we do
mass Python 3.8 rebuilds. The answer was... it's complicated. (I can search the
devel list if you want details.)
As an example, if I want to see what requires python2 on rawhide, I don't see
any modules there (this was couple months ago, the situation may have changed
now but will repeat when f32 branches).
This is not relevant to the "make modules non-viral" goal.
So, no, I don't believe Ursa Prime achieves the goal. But I might
just be not
informed well, because the Ursa Prime change proposal is not informational
enough in this regard. In that case, sorry for spreading panic.
Ursa Prime is not an ultimate answer to everything, it is a tool which
provides a specific functionality.
As I mentioned earlier, blocking the development of a tooling leads to
a deadlock: we can not have a good solution because there are no tools
for it, and there are no tools for it because we don't have a good
> As well as policy which restricts the set of default modules,
> think we need to change from "FESCo approves new default modules" to
> "each request for new default module should be treated as a
> System-Wide Change".
And I think it needs to change to: no default modular streams.
Yes, once all the concerns that I and our community members I choose to
represent have are settled, we can revisit this. But that doesn't mean we should
explicitly treat it as a temporary policy.
> Again I fail to see the _technical_ difference between the ursine rpm
> package and a package which was built as a part of default stream.
The _technical_ difference is that it's built differently, from a different
place, in a different way, with different rules. And if we "fix" that, we no
longer have default modular streams.
To clarify: Another _technical_ difference are broken upgrades, but that can be
fixed, so I treat that behavior as a bug and will not use it as an argument.
However, if it is proven that we are not able to fix it, it may become an
argument as well.
> is the same rpm spec from the same dist-git sources, which is built by
> the same rpmbuild command.
It is some kind of spec file, build from some arbitrary dist-git branch built by
the same rpmbuild command in an alien environment.
> Thus I think it is a process/policy
> difference, which we should resolve.
It is. And you know what I think the policy should be. No default modular streams.
It s hard to discuss the topic when one of the sides doesn't accept
even the possibility of another solution.
> And I will support a hard block on creating new default streams,
> it is resolved.
We don't agree on what "is resolved" means here.
> (With the exception of eclipse probably, which is in a broken state
> already, and for which we need to find a solution.)
As a hypothetical example, if we grant eclipse an exception based on the fact
that it is broken and eclipse gets a modular default stream and another software
is broken by the same way eclipse was broken because of that, do we give it an
exception as well? And another? And another?
As a second (even more) hypothetical example, if a maintainer decides they
really really want their default modular stream, could they just choose to not
solve all the FTBFS bugzillas and orphan their packages and ask for default
modular stream based on the fact that their package doesn't install or build in
regular Fedora? Would we grant them an exception?
This really has nothing to do with Modularity.
Maintainers can always orphan their packages. And FESCo or Council or
anyone else can not really prevent it from happening.
We are community project and we are negotiating decisions between all
If maintainer explicitly uses a threat to orphan packages as a way to
bypass FESCo decisions instead of contributing to them, then it would
mean that yes, we failed very badly in our negotiations round.
But it would also mean that it might be the time to go through that
orphaning process, accept the losses and move on.
It is not an easy decision to talk about it purely hypothetically.
And it is not the case of eclipse, where FESCo decision on default
streams came after the work on eclipse modularization was done.