On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes <t...@compton.nu> wrote: > So basically the module squad have managed to ensure that everything > that relies on ant to build is going to have to modularise or else be > forced out of the distribution then... > > Fortunately that only includes one thing of mine and that's just some > java bindings that I can drop but forcing libreoffice out of Fedora on > the hill of modularisation will certainly be an achievement of sorts.
They say the easiest way to learn the right answer is to post the wrong answer on the internet. Here is my “wrong” answer that I hope someone will correct so my context on this thread is correct. As a user who wants to run a piece of software: * I can run software like LibreOffice in a flatpak that works like a container (not identically) and I can get it via a dnf-like command line tool or the GUI software store. When I run the app I can’t tell it is in a flatpak. If the app isn’t graphical I can generally achieve the same effect with a container and some knowledge of container runtime configuration. * I can enable a module that provides the software using a dnf command. At that point the dnf command installs the software as though it was in the “everything” repo. Once the enable command is run I can’t tell that the software is delivered as a module. As a developer who relies on a dependency that is module only: * I can build in containers and on my local machine by enabling the module. This causes dnf and dependency installs to work as though the contents of the module were in the “everything” repo. * Today, I cannot build packages for the “everything” repo that have runtime or build dependencies on modules. Work is being done to allow build dependencies that are in a module to be used. Overall, as a user, to a large degree, the delivery mechanism (rpm, container/flatpak, and module) doesn’t affect me, except briefly at install. Overall, as a developer, today if my dependencies are modules, I have to build a module. Tomorrow if my runtime dependencies are modules I have to build a module, but otherwise I can build an “everything” repo rpm. I can deliver via container or flatpak today no matter what. As a system administrator, if my machines have internet access I may have to learn a few new commands, but it all works. If my machines are getting their software indirectly, my experience will vary based on whether my indirection server can handle modules, flatpaks and containers. Is this close to right? Regards, bex > > Tom > > On 12/02/2019 09:03, Igor Gnatenko wrote: > > Not in the buildroot. Default modules are available by default only for > > users and not in the buildroot. > > > > On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes <t...@compton.nu > > <mailto:t...@compton.nu>> wrote: > > > > On 12/02/2019 07:22, Mikolaj Izdebski wrote: > > > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini > > <decatho...@gmail.com <mailto:decatho...@gmail.com>> wrote: > > >> I'm curious: What happens to modules when a package's master > branch > > >> gets retired? > > > > > > Nothing. Modules will continue to exist and will continue to be > > > delivered to users. > > > > But as I understand it the default module stream is available > > in master anyway? > > > > So that does mean ant is a false positive because it's still > > available as a module and the default stream will be available > > in master? > > > > Tom > > > > -- > > Tom Hughes (t...@compton.nu <mailto:t...@compton.nu>) > > http://compton.nu/ > > _______________________________________________ > > devel mailing list -- devel@lists.fedoraproject.org > > <mailto:devel@lists.fedoraproject.org> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > <mailto:devel-le...@lists.fedoraproject.org> > > 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@lists.fedoraproject.org > > > > > > _______________________________________________ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > > > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
