On Mon, May 28, 2018 at 11:36 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
>
>
>
> On Mon, May 28, 2018 at 11:16 AM, Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>>
>> On Mon, May 28, 2018 at 11:13 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
>>
>>
>>
>> > On Mon, May 28, 2018 at 11:05 AM, Fabio Valentini <decathorpe@xxxxxxxxx>
>> wrote:
>>
>> >> On Mon, May 28, 2018 at 10:58 AM Petr Šabata <contyk@xxxxxxxxxx> 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 <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
>>
>> >> 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.
Thank you!
This time I was able to successfully herd the gophers far enough to be able to push my update for syncthing.
However, since the golang ecosystem seems to get worse over time, I'll come back if I have questions regarding the modularity route :)
Fabio
>>
>>
>>
>>
>> >> > * 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@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/
>> >> _______________________________________________
>> >> 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/Y2RRCYPTCK7WN6ZSC3XOCNX3Z2SA7XF5/
>>
>>
>>
>>
>> > --
>>
>> > Adam Šamalík
>> > ---------------------------
>> > Software Engineer
>> > Red Hat
>> > _______________________________________________
>> > 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/VWYRTM33EGD5FSIBZOBVLIZS2JDO3PTJ/
>> _______________________________________________
>> 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/Q7WQJCR6JKOE7SS5ZSQYHL3JQBUYTKF2/
>
>
>
>
> --
>
> Adam Šamalík
> ---------------------------
> Software Engineer
> Red Hat
> _______________________________________________
> 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/VNUYHZH2DKC3AOF4PLMAROEEU54Z5XDS/
>
>
>
> On Mon, May 28, 2018 at 11:16 AM, Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>>
>> On Mon, May 28, 2018 at 11:13 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
>>
>>
>>
>> > On Mon, May 28, 2018 at 11:05 AM, Fabio Valentini <decathorpe@xxxxxxxxx>
>> wrote:
>>
>> >> On Mon, May 28, 2018 at 10:58 AM Petr Šabata <contyk@xxxxxxxxxx> 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 <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
>>
>> >> 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.
Thank you!
This time I was able to successfully herd the gophers far enough to be able to push my update for syncthing.
However, since the golang ecosystem seems to get worse over time, I'll come back if I have questions regarding the modularity route :)
Fabio
>>
>>
>>
>>
>> >> > * 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@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/
>> >> _______________________________________________
>> >> 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/Y2RRCYPTCK7WN6ZSC3XOCNX3Z2SA7XF5/
>>
>>
>>
>>
>> > --
>>
>> > Adam Šamalík
>> > ---------------------------
>> > Software Engineer
>> > Red Hat
>> > _______________________________________________
>> > 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/VWYRTM33EGD5FSIBZOBVLIZS2JDO3PTJ/
>> _______________________________________________
>> 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/Q7WQJCR6JKOE7SS5ZSQYHL3JQBUYTKF2/
>
>
>
>
> --
>
> Adam Šamalík
> ---------------------------
> Software Engineer
> Red Hat
> _______________________________________________
> 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/VNUYHZH2DKC3AOF4PLMAROEEU54Z5XDS/
_______________________________________________ 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/3PMTMTITA5GPIAUZZEAEPELULMRIC4Y3/
