Re: [PATCH] python: Add Python bindings for libgsasl

[Greg Troxel]

Simon Josefsson <address@hidden> writes:

> Definitely.  As you discussed with Greg, I believe there are three
> options: 1) distribute separately, 2) distribute it from the same
> repository/tarball as upstream gsasl (i.e., integrate it into the build
> system so that it is installed when you install gsasl), and 3) make it
> part of the upstream project, but have it as two separate deliverables.
>
> Traditionally, I've been in favor of 2) since it leads to users getting
> everything from the package in one go, and everything gets tested as
> part of the normal release process.  People can disable things they
> don't want.

My point, in case I didn't explain well enough, is that "people" isn't
the right target, since almost all uses of software are via package
management systems.  So thinking about a person building from source,
while it 100% has to work and is how almost all contributions come in,
is a vanishingly small use case overall.

With a packaging system, foo and py-foo will be separate packages,
because it's not reasonable to make users of foo have python installed,
or to make the build of the foo package depend on python.  (I realize
some packaging systems essentially only care about binary users and make
building from source require the union of all possible dependencies.
Such systems are awkward for those building from source, and tend to
lead to ecosystems where almost all users only run binaries.)  So there
will be two packagees, one that does not depend on python, and one that
will depend on the first pacakge and python.  These can be built from
the same tarball, or two tarballs.  It really doesn't matter, as long as
the builds are independent.  It also doesn't matter if there's an option
to build it all at once, for the handful of
compiling-from-source-by-hand users.

If the builds aren't independent, then either packagers kludge around
the problem in the build system by patching out targets in makefiles
(and this is ugly, error prone, and a pain to maintain), or they don't
bother and just omit the py-foo version.

Practically, I think two tarballs are likely to lead to fewer problems
for the packaging case, because it naturally falls to two separate
packages.  Whether you release them in sync or not doesn't matter to
packagers, as long as it's always true that the latest release of each
work together.

So I am basically splitting your 2 into 2a (detect python and if present
build py-gsasl) and 2b (run python build stuff in the python directory,
and have that expect that gsasl is already installed and ignore the
gsasl proper part of the tarball), and saying I'm find with 2b and that
2a leads to a mess.

This is all from the perspective of maintaining packages in pkgsrc,
where it's very normal to build from source, or to use binary packages.

pgpeu1qewElnl.pgp
Description: PGP signature