On Mon, May 28, 2018 at 11:16 AM, Fabio Valentini <decatho...@gmail.com> wrote:
> On Mon, May 28, 2018 at 11:13 AM Adam Samalik <asama...@redhat.com> wrote: > > > > > On Mon, May 28, 2018 at 11:05 AM, Fabio Valentini <decatho...@gmail.com> > wrote: > > >> On Mon, May 28, 2018 at 10:58 AM Petr Šabata <con...@redhat.com> wrote: > > >> > On Sat, May 26, 2018 at 05:00:43PM +0200, Fabio Valentini wrote: > >> > > On Sat, May 26, 2018 at 3:44 PM Neal Gompa <ngomp...@gmail.com> > wrote: > >> > > > >> > > > On Sat, May 26, 2018 at 9:35 AM Fabio Valentini < > decatho...@gmail.com> > >> > > > 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 > > >> Yes, Neal also pointed that out to me - but it doesn't help if the > required > >> dependency has to be newer than anything that has ever been packaged for > >> fedora, does it? > > > > Modules can only include RPM packages — so having an upstream dependency > which is not packaged is not gonna work. But if you package it yourself > (possibly in a stream branch), you'll be fine. > > Yes, that's exactly what I would do, because the "normal" branches of those > dependencies can't / won't be updated to the version I need because of > arising conflicts. > Exactly. I'm one of the people directly involved with Modularity — feel free to ask me questions, I'm happy to help. > > > > >> > * 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 > >> > _______________________________________________ > >> > 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/message/2XSSRRCHAKOFCSHJ5NMVWK2LHFEXOA5W/ > >> _______________________________________________ > >> 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/message/Y2RRCYPTCK7WN6ZSC3XOCNX3Z2SA7XF5/ > > > > > > -- > > > Adam Šamalík > > --------------------------- > > Software Engineer > > Red Hat > > _______________________________________________ > > 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/message/VWYRTM33EGD5FSIBZOBVLIZS2JDO3PTJ/ > _______________________________________________ > 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/message/Q7WQJCR6JKOE7SS5ZSQYHL3JQBUYTKF2/ > -- Adam Šamalík --------------------------- Software Engineer Red Hat
_______________________________________________ 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/message/VNUYHZH2DKC3AOF4PLMAROEEU54Z5XDS/
