Fedora guidelines: All packages whose upstreams allow them to be built
against system libraries must be built against system libraries.

So if zstd could become a standard system library it would have to be
unbundled.

On Wed, Nov 23, 2016 at 8:01 AM Dirkjan Ochtman <dirk...@ochtman.nl> wrote:

> On Tue, Nov 22, 2016 at 9:53 PM, Gregory Szorc <gregory.sz...@gmail.com>
> wrote:
> > I'm sending this email to reach out to packagers so we have time to
> address
> > packaging concerns around zstd. I'm willing to make upstream changes to
> both
> > Mercurial and python-zstandard to ease packaging issues. Please read the
> > aforementioned commit messages to understand the vendoring decision and
> then
> > let me know if there is anything I can do to make your life easier.
>
> Very interesting work!
>
> On Gentoo Linux, we definitely prefer unbundling vendored libraries.
> For autotools build systems, we ideally get a --use-system-zstd or
> similar that will disable usage of the bundled dependencies and use
> the normal header and library path environment variable to find it.
> I'm not really sure how that fits into distutils stuff, though.
>
> Given the static linking requirements between python-zstd and zstd, an
> easy improvement here would be to make the install of the bundled
> python-zstd optional, so that our package manager could just install
> the system python-zstd instead. In that case, it would be important
> that a requirements.txt or similar lists the version of python-zstd
> used, and ideally any changes to that version would also figure
> prominently in future changelogs.
>
> Cheers,
>
> Dirkjan
> _______________________________________________
> Mercurial-packaging mailing list
> Mercurial-packaging@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-packaging
>
_______________________________________________
Mercurial-packaging mailing list
Mercurial-packaging@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-packaging

Reply via email to