On Sat, May 26, 2018 at 9:35 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > Hi all, > I think I finally found a scenario where building some of my (and others') packages as modules would be beneficial. > The situation is: > - The syncthing package has a lot of golang dependencies. > - Some of them are too old in fedora, even in fedora rawhide, and some of them have not been touched in years. > - However, some other packages may depend on those older versions, or the packagers don't have time to check for compatibility. > The idea for a solution I came up with: > - Build syncthing as a module. > - Add "syncthing" branches to all incompatible dependencies (I guess I have to request commit/admin access to do that for packages I don't own yet?). > - Update those branches to use the exact same commit as the vendored sources in upstream syncthing. > - Use those modules as dependencies for the syncthing module. > Is that a valid, feasible use case of modularity? You can kind of pigeonhole it into that, but I think you might be better served by vendoring things you can't use from Fedora packages and going from there. The problem is that you're touching other people's packages and hoping they don't make those branches go away. And at the end of it, the output would be a single package that lives outside of the normal repo metadata and only modularity-enabled clients would be able to install it. The excludes most of the package managers that people can use in Fedora right now. It might make sense if you could describe which dist-git commit to use in the module definition, regardless of what's actually released in the main repos, and it would just build from those until you upgrade it. That would avoid the need for branches in all the golang packages you need for syncthing. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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/message/DABQYU6UORCGF7TO5EQFKX5KGS457QZX/
