On Mon, May 28, 2018 at 10:58 AM Petr Ĺ abata <contyk(a)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(a)gmail.com> wrote:
>
> > On Sat, May 26, 2018 at 9:35 AM Fabio Valentini <decathorpe(a)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?
* 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.o...