On Wed, Nov 13, 2019 at 12:00 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > 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. 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 solution. > > 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. 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, 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? 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 contributors. 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. -- Aleksandra Fedorova bookwar _______________________________________________ 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
