Quoting Stefan Weil (2022-01-19 18:07:28)

Am 19.01.22 um 17:43 schrieb Thomas Koch:

I searched but apparently this has not yet been discussed anywhere below lists.debian.org.

My package ships two convenience copies from autoconf-archive in it's m4 folder. Should I

a) leave these files and add the corresponding data to d/copyright or
b) leave these files and don't bother about d/copyright or
c) remove these files and add build-depend on autoconf-archive, linking the files before dh_autoreconf?

Apparently I'm not the only one with uncertainty here: https://bugs.debian.org/949119

Thanks for your guidance, Thomas

As I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949119#15
autoconf-archive is not needed for building because the two required
files are also provided as part of the Tesseract source tree.

Technically all options a), b) and c) use exactly those two files either
from the Tesseract source tree or from autoconf-archive during the build process. Nothing of those files is part of the build results which get installed. So a binary install package does not require a copyright
notice for any of those files.

I don't know the Debian rules for source packages. Do they require an
extra documentation of all copyrights for any file in the source distribution? The licenses of both files don't demand that.

Thanks for elaborating.

The concern is not licensing, but maintenance. It is covered in Debian
Policy § 4.13: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Kind regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============(94338054807465106=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHoTeoACgkQLHwxRsGg ASHZ1Q//VQz30pNR1FvEco75H5JUaY5N1wIIK3qRvM0BsXlt6HlCE9V96CfLoHae bgobWGg6ADD0gwpb50ikx3Tz7WcDJyCvBjXTgeDCuJFSIcOrTCfMJqb0EPit++H7 7/nie8nSr5uslNYLqZcpxpGGF2J5kMudyNpaUgLzDDriPIb0g8LdZ9974uA80xkt CYBVLUbu5HSBz/VzNbSJSJZsn+YhWpj0QASuAYuh8VkrpcEWPs5AFq4dWIqntW0I rchJn9E5M8sSceoXpCQMAtz/ceRNkobeBdQiQONTYOf9ex0EOIz2fLwEgIaqNa5w jY227TnL3X68k912MCdf27ZXmjzdNzc1lkaMhFPgzFQu+5670pHlCJ10/Qm6rJ6o o7q1u+zipF2TJ5dNgzC5u2DpT25gX8fLx6o8SwYI8arEU/gP0wAhY2O/EfQvmXV+ PRDcOKHmCspi4TrOpxphR8pqH/Hrb7mkZchqhjQiSHQPbACz+cNll5HROBOMKmI7 d73sxOJeMefWfdTPi

Quoting Thomas Koch (2022-01-19 17:43:39)

I searched but apparently this has not yet been discussed anywhere below lists.debian.org.

My package ships two convenience copies from autoconf-archive in it's m4 folder. Should I

a) leave these files and add the corresponding data to d/copyright or
b) leave these files and don't bother about d/copyright or
c) remove these files and add build-depend on autoconf-archive, linking the files before dh_autoreconf?

Apparently I'm not the only one with uncertainty here: https://bugs.debian.org/949119

Thanks for your guidance, Thomas

Please avoid embedded code copies whereever possible - this sounds
easily possible to avoid, so please do that.

I don't follow the argument in bug#949119 that upstream embedding for a
long time somehow makes it better that Debian preserve embedded copies.

NB! Depending on build routines you may not need to manually link (or
copy) files around - they may be automatically copied in by autotools.
I.e. there might be another option:

d) remove these files in target "clean" (and also repackage source, unless you want to track copyright for those unused files), add build-depend on autoconf-archive, letting dh_autoreconf do its magic?

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============b04188682322409285=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHoRtYACgkQLHwxRsGg ASGl0A/+IEmPvHIPyawvJLf94BzdPzjWAsL+8T1D8bJ4olUhnBmYMnBG1MwZT4kN g4dJcuXhjIrUfP42WjFOo9PAbuIaFJPca5dvFEOGiP+oEck0+A+qeDmP/HEJt1xI T0+3gejNBlVx9HQuGCJyopQ/wLGMjhlNrhHedNLqa6YalzCot+FKbtjz5ubWghkQ 4GDXhP6044Tt2aL0D9/WITRXQ9su3qqg2W9THUDoWVcxvC6PQU1eycHnEnbxuPxe ZUMUYuNT3RLOlP76jHqouLWJUb7HQFI6Aqsk9Y5ytoy/YVoNat+LEHI0Xtgi8F+z 2zVfi+/0gm4zUEy9JTajucJqwoqIFgSz0Je9vEpps+FEe+0jRvNhWVq3cCacWvny Qrw2S6TZGZokvEUuS8h4+7Xe9Xt8lSKyRFPBUc/lPjTO5/wCYivFnYpxpoo/A5Ke j4OMUei6MCAkBWbGHRa/LCchEtOIK9Kw8u9Giegu21BzUCmDsauGLNCM6O9c/5sJ 9pujz5zccFfmrf9GQ

Am 19.01.22 um 17:43 schrieb Thomas Koch:

I searched but apparently this has not yet been discussed anywhere below lists.debian.org.

My package ships two convenience copies from autoconf-archive in it's m4 folder. Should I

a) leave these files and add the corresponding data to d/copyright or
b) leave these files and don't bother about d/copyright or
c) remove these files and add build-depend on autoconf-archive, linking the files before dh_autoreconf?

Apparently I'm not the only one with uncertainty here: https://bugs.debian.org/949119

Thanks for your guidance, Thomas

As I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949119#15
autoconf-archive is not needed for building because the two required
files are also provided as part of the Tesseract source tree.

Technically all options a), b) and c) use exactly those two files either
from the Tesseract source tree or from autoconf-archive during the build process. Nothing of those files is part of the build results which get installed. So a binary install package does not require a copyright
notice for any of those files.

I don't know the Debian rules for source packages. Do they require an
extra documentation of all copyrights for any file in the source
distribution? The licenses of both files don't demand that.

Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 19.01.22 um 18:44 schrieb Jonas Smedegaard:

Quoting Stefan Weil (2022-01-19 18:07:28)

As I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949119#15
autoconf-archive is not needed for building because the two required
files are also provided as part of the Tesseract source tree.

Technically all options a), b) and c) use exactly those two files either
from the Tesseract source tree or from autoconf-archive during the build
process. Nothing of those files is part of the build results which get
installed. So a binary install package does not require a copyright
notice for any of those files.

I don't know the Debian rules for source packages. Do they require an
extra documentation of all copyrights for any file in the source
distribution? The licenses of both files don't demand that.

Thanks for elaborating.

The concern is not licensing, but maintenance. It is covered in Debian Policy § 4.13: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Kind regards,

- Jonas

Generally I fully agree that embedding code from other projects is a bad
idea for obvious reasons.

In this case I decided to do it nevertheless.

We are talking of these two files:

% wc m4/ax_*
      53     224    2104 m4/ax_check_compile_flag.m4
      38     114    1274 m4/ax_split_version.m4
      91     338    3378 total

The Debian autoconf-archive is nearly 6 MB. We had used autoconf-archive
since 2016. I removed that dependency in May 2018. Citing my commit message:

    Remove autoconf-archive dependency

    It creates much confusion and causes many issue reports,
    so let us drop this dependency.

    The two new files in the m4/ directory are current copies from GitHub
    (https://github.com/autoconf-archive/autoconf-archive/).

Although I build a lot of different open source projects, I never missed autoconf-archive after I had removed it from my build machines. It is
rarely required (= only by the former Tesseract code in my personal
experience) and therefore never preinstalled as far as I know. And
getting it can be really time consuming. Tesseract builds must work on
Linux / macOS / Windows in different variations, also on hosts where the
user has no root permission for installation of additional packages. The
FSF has machines in its build farm which not even have access to GitHub
to get a local copy of autoconf-archive.

As both files are rather small, simple and only used by configure, there
are no related security risks, and maintenance is rarely needed. And I
simply don't want to reinvent the wheel for checking compile flags or
splitting the version string because that's also no good alternative.

Regards

Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jonas Smedegaard <jonas@jones.dk> writes:

Thanks for elaborating.

The concern is not licensing, but maintenance. It is covered in Debian Policy § 4.13: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Debian packages should not make use of these convenience copies unless
the included package is explicitly intended to be used in this way.

The part after the "unless" is the case for autoconf-archive upstream:
shipping a copy with your package is how it is intended to be used.

One can disagree with that statement in Policy, of course (I think it's debatable and there are some benefits to pulling everything from the
original source even if it is intended for use as an embedded copy), but I didn't want to leave the thread with the impression that Policy supports a dependency here. It does not; since this meets the "unless" condition,
Policy expresses no opinion on a dependency versus an embedded copy,
either for or against.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2022-01-19 at 18:43 +0200, Thomas Koch wrote:

My package ships two convenience copies from autoconf-archive in it's
m4 folder. Should I

In my experience with libpst, it had embedded copies of Python/boost
macros from autoconf-archive that were modified and the modifications
hadn't been sent back to autoconf-archive upstream and they changed the
API of the macros in a way that was incompatible with the upstream API
and caused FTBFS when using the autoconf-archive upstream macros
because configure.ac used the modified API instead of the upstream API.

My solution to this was to get a patch into libpst upstream switching
to the autoconf-archive upstream API. That patch later got reverted, so
that the package would build on CentOS 6 direct from the VCS. Later
upstream orphaned libpst so I took over the project, removed the m4
files and promptly rediscovered, redebugged and refixed the issue.

So my suggestion to you is to figure out which version of the macros
from which autoconf-archive version you have, then figure out if they
are modified, then discuss the situation with upstream to ensure they understand the situation and won't revert any patch, then send upstream
a patch if they like the idea, then switch from the upstream tarballs
to the upstream VCS for the Debian orig.tar.gz, so that prebuilt files
(like ./configure) and embedded copies aren't present in the Debian
orig.tar.gz and you can be certain that Debian can rebuild the build
system accurately solely from Debian packages. Optionally it would be a
good idea to compare the upstream tarball with the upstream VCS and
account for any differences between the two.

Personally I'd really like autotools tarball to be changed to create
multiple tarballs instead of one. One with VCS contents, one with
autotools embedded copies (config.guess, m4 macros etc), one with other embedded copies, one with autotools prebuilt files and one with other
prebuilt files. Then users and distros could choose how many of the
upstream tarballs to consume.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmHowjwACgkQMRa6Xp/6 aaOnPA/7Bszns5E12xZ1U0bSzTn5OPi2Bnt74X26NHpnhpAJX0cI/5wBOINLaH+W y8h4M6GkLghrFS5aucmX1HwrfFDbddZRCH97g+8CClqyhXJ32IlI7ebgoKTMbFVY FW33ObahNsmL/NYQIo8pVNS59lcn3Rv3rBhuikxmtb42o4OR4mrbjHtiONcsh5di 9bKcSgB41cqKqAjaqjhR16o1ZcS0rKd+X392GnwLsJ8VJWIFHWUt0tapXRBmhh4T IhZBGFUQb91yzoY4kY5xCSSpMu4qIlMia3ve0uCh86aN5CQhLthacLNbj1xbY4G0 jBIOPQ3T2DE7zYItBsXEAsgFrhagaTK9AefvlaUm7yXBXPkW8oWyM0tVUF5aPRYG wY98P/3o4Gym4Xcozygx/9MJKTuZX+0uZuBQdon7qL0nEK+2wfby7u+jXk3UIv+v Pw7V+0VX2M4uWE/4PKEdv9+qyEyCEEeG2a5P5+T3T+mTf4zRGSFnYRMpIIOOEiBR eTSMVQ7qPeMakG25Wcq19tl8AMwbQt5qrv/XqUvKrZR6q1Zv/0hevxd1tAVZQM/0 fJY5joUTY2H36qHKRIVpU3w8QqfwrT7pt4l0AmcjKjQSgEC23t44NWwrwDRNk9uE jqf3kwS2m+2+Xrz3bc3Xutki9LFV+gfngbQMJvfn3afr9yvtKOE=
=tpKn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-01-19 11:03:15 -0800, Russ Allbery wrote:

Jonas Smedegaard <jonas@jones.dk> writes:

Thanks for elaborating.

The concern is not licensing, but maintenance. It is covered in Debian Policy § 4.13: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Debian packages should not make use of these convenience copies unless
the included package is explicitly intended to be used in this way.

The part after the "unless" is the case for autoconf-archive upstream: shipping a copy with your package is how it is intended to be used.

FYI, this is what we now do in GNU MPFR (there's only one file),
after we got a failure due to the upgrade to Autoconf 2.71: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985458

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)