On Sat, May 26, 2018 at 05:00:43PM +0200, Fabio Valentini wrote: > 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. I might not be following but: * you can link to any git refs -- branches, tags, or commits * if you branch the dependencies, it's really up to you to maintain those; that also means you can use any versions and patches I think modularity could solve your problem provided that you are fine with the syncthing module overriding those dependency packages when people enable it. Neal's comment on support in package managers is valid. This will get better over time but the current state of things is also something to consider. P
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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/2XSSRRCHAKOFCSHJ5NMVWK2LHFEXOA5W/
