Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Tue, Jun 18, 2019 at 1:33 PM Nicola Di Lieto wrote:
> The tarball is also signed with the same key in the dsc file
>
> https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.16-1.dsc
I was referring to detached signatures over the tarball here,
distributed via github.
> I will definitely not delete configure, Makefile.in and their friends
> from the upstream releases because other systems than debian also use
> uacme and I want to preserve, as is customary, the ability to do
> './configure && make install'.
That is what the `make dist` tarball is for, they shouldn't be in
version control.
> In addition build-aux/git-version-gen and build-aux/m4/* are not
> generated. If I deleted them autotools would not be able to regenerate
> the configure script anymore.
Where do they come from? If they are copied in from other places, then
they shouldn't be in git (just `make dist` tarballs). If they are
written for and maintained for uacme they should be in git. Looking at
git-version-gen, it seems to come from autotools somehow. Looking at
build-aux/m4/* it seems they come from autoconf-archive. IMO both
should be removed and copied in at `autoreconf -sif` time so they are
available in `make dist` tarballs.
> As an example, uacme is now being packaged for OpenWRT:
> https://github.com/openwrt/packages/pull/9150 and there they don't want
> to regenerate configure and the manuals. All they care is that it gets
> built. We might disagree with their approach but then again they could
> disagree with debian's. So I am being pragmatic and trying to support
> both.
You could setup `make dist` to build/include the generated manual page
artefacts for platforms that don't build everything from source.
I have been thinking about writing an autotools mode that splits the
upstream tarball into multiple tarballs, including: VCS-equivalent
tarball, autotools cruft tarball, architecture-all tarball, etc.
> I think in the end what matters for debian is that everything is
> regenerated from source cleanly, which is the case.
Agreed.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: