On Mon, Nov 5, 2018 at 5:13 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > This is related to an open ticket to Release Engineering > (https://pagure.io/releng/issue/7840) which was brought to FESCo > (https://pagure.io/fesco/issue/2003). Until now, I've been mostly keeping quiet about the whole modularity thing - in part, because I disagree with the direction the concrete implementation has been taken in; I didn't see it as useful to me, and it has not impacted me as a packager who only builds standard packages. TL;DR: I want to keep it that way (at least for now). > We understand the need to > enable this, but there is an impact to workflow for local builds. It > is possible that some of this could be alleviated with a fairly simple > change to mock. What exactly does "could be alleviated" mean here - would that "simple change" to mock make it just 90% more cumbersome, instead of 100%? What would the new workflow look like? > The ability to install all builddeps with dnf builddep will be a bit > more difficult. A bit more difficult ... how, exactly? Do I have to solve the Riemann Hypothesis before calling that command - or what would be the added difficulty here? > Of course local builds where the build deps are > already installed will not be impacted. Do you mean host-system-local, or mock-local builds? Because I don't even have the "-modular" repositories enabled on my f29 system, and I'll keep it that way. > With this in mind, we wanted > to open this up to some discussion on list before we make a decision. I have to say, making core, non-leaf packages available as modules only sounds like a *terrible* idea to me. I don't want to have to deal with this uncooked mess if I just want to do standard packaging. Heck, as things stand right now, I'd even volunteer to maintain "standard branches" of my dependencies which are "in danger" of being converted to module-only, just to not have to deal with modules. I understand that modularity can have benefits for some work-flows and some specific packages, but this effort sure looks like jumping on the band-wagon just because it's the new, shiny thing, without considering the consequences. Please don't take this criticism the wrong way - I acknowledge that releng and FESCo are doing hard work here. I'm just not convinced that this work is actually benefiting fedora as a developer platform / platform to develop for. Fabio > Thanks, > Justin > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
