On 12. 11. 19 18:25, Aleksandra Fedorova wrote:
On Tue, Nov 12, 2019 at 5:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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 the
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 currently not
possible. My proposal to keep all defaults as non-modular packages would make it
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 my
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.
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).
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.
As well as policy which restricts the set of default modules, which I
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.
It
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.
And I will support a hard block on creating new default streams, until
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?
--
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
