On Sat, May 26, 2018 at 3:44 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > 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. I don't think that would be the case. An upstream commit that's newer than anything that has ever been packaged before for a fedora branch is never available, not even if I could target other dist-git commits. That's why I thought of modularity. > -- > 真実はいつも一つ！/ 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/ _______________________________________________ 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/HHZPNOCZNZVEY4WFFCUG76662XJWU73O/
