On Mon, May 28, 2018 at 11:13 AM Adam Samalik <asamalik@redhat.com> wrote:



> On Mon, May 28, 2018 at 11:05 AM, Fabio Valentini <decathorpe@gmail.com>
wrote:

>> On Mon, May 28, 2018 at 10:58 AM Petr Šabata <contyk@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 <ngompa13@gmail.com>
wrote:
>> > >
>> > > > On Sat, May 26, 2018 at 9:35 AM Fabio Valentini <
decathorpe@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.

>> > * 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-leave@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-leave@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-leave@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-leave@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/