[Pkg-shadow-devel] out of my depth

[Serge E. Hallyn]

On Wed, Nov 30, 2016 at 12:47:19AM +0100, Bálint Réczey wrote:
> 2016-11-30 0:45 GMT+01:00 Bálint Réczey <balint at balintreczey.hu>:
> > Hi,
> >
> > 2016-11-27 9:02 GMT+01:00 Mike Frysinger <vapier at gentoo.org>:
> >> On 25 Nov 2016 13:42, Serge E. Hallyn wrote:
> >>> On Tue, Nov 22, 2016 at 02:23:56AM +0100, Bálint Réczey wrote:
> >>> > 2016-11-22 2:19 GMT+01:00 Serge E. Hallyn <serge at hallyn.com>:
> >>> > > Quoting Bálint Réczey (balint at balintreczey.hu):
> >>> > >> Hi Serge,
> >>> > >>
> >>> > >> I started reviewing the new package. The changes in Debian look good
> >>> > >> but the generated
> >>> > >> files in the original tarball do worry me.
> >>> > >> Those are not present in tag 4.4 in upstream repository.
> >>> > >
> >>> > > Hi,
> >>> > >
> >>> > > Are you talking about the po/*.gmo files?  They keep getting
> >>> > > autogenerated now witha 'make dist'.  That is what the first email
> >>> > > in this thread was asking about, in particular:
> >>> > >
> >>> > > |>> autogen.sh calls autoreconf which calls autopoint, which creates
> >>> > > |>> m4/po.m4, which creates po/Makefile.in.in, which creates a makefile
> >>> > > |>> which ends up calling
> >>> > > |>>
> >>> > > |>> cd $(srcdir) && rm -f $${lang}.gmo && $(GMSGFMT) -c --statistics -o t-$${lang}.gmo $${lang}.po && mv t-$${lang}.gmo $${lang}.gmo
> >>> > > |>>
> >>> > > |>> etc.  The *.gmo files are binary ones, which we don't want to be
> >>> > > |>> shipping iiuc.  So - what is an ignorant packager to do?  It seems
> >>> > > |>> like there must be an obvious flag to add to autoreconf in autogen.sh,
> >>> > > |>> but I can't find it.
> >>> > >
> >>> > > So they are not in the git tree but they are in fact in the upstream tarball.
> >>> > > I could manually pull them out of the packaging source.orig.gz if that's
> >>> > > the right thing to do...
> >>> >
> >>> >
> >>> > Please don't use make dist.
> >>>
> >>> Huh.  That's the first time I've heard that suggestion.
> >>
> >> it's a bad suggestion in this case.  some people try to be super strict
> >> in that the releases are always reproducible from git.  while that might
> >> work for some projects, it doesn't for ones that use a generated build
> >> system like autotools.  in order to pull it off, you'd have to actually
> >> commit the generated output (e.g. "configure" and "config.h.in" and all
> >> the rest) to git which is an even worse idea.
> >
> > I may not have been clear enough, but I had no intention to suggest
> > storing generated files in git. This would be a bad idea. I would like to ask
> > for basing the Debian package on a tarball _not_ containing generated
> > files such as Makefile.in.
> >
> > Reviewing changes when autogenerated files pollute the diff is harder
> > and shadow is an important package.
> >
> > Note that 4.2-3 did not have generated files in the source package:
> > $ git diff --stat debian/4.2-3  | head
> >  .gitignore                                         |    47 -
> >  ABOUT-NLS                                          |  1101 +
> >  Makefile.in                                        |   852 +
> >  aclocal.m4                                         | 12674 +++++++++++
> >  autogen.sh                                         |    12 -
> >  compile                                            |   347 +
> >  config.guess                                       |  1441 ++
> >  config.h.in                                        |   603 +
> >  config.rpath                                       |   614 +
> >  config.sub                                         |  1813 ++
> >
> >>
> >>
> >> so when making shadow releases, you should be using `make distcheck`.
> >> you can then attach the tarball to the github page under the releases
> >> section.
> >
> > Why? Who can't use the git archive output?
> > In Debian you have to regenerate all generated files in the source package
> > or prove that they can be regenerated. How do you prove that for all
> > the files in the dist tarball?
> >
> > Tomorrow I'll update the packaging repository and show what I meant.
> 
> BTW when importing new upstream please push the upstream branch and
> tag to the packaging repo because git-buildpackage needs those.

Hi,

I hadn't wanted to pollute the git tree with my attempts, but I went ahead
and pushed an older branch.  Also, my most recent packaging is at

https://mentors.debian.net/debian/pool/main/s/shadow/shadow_4.4-1.dsc

Note the git tree is *behind* the package posted at mentors.  Sigh, I'm now
regretting having pushed that.

I'll urge you to keep in mind that several debian developers appear to have
different opinions on the best way - so if you intend to maintain the package
then that's great, if not then insisting on specific workflows (like using
git) to sponsor a package seems unhealthy.  And in general, manufacturing a
git tree from another git tree and existing package, in order to re-generate
the package, seems like begging for trouble and frustration.

Dropping the .gmo files certainly seems to be agreed-upon, and the package on
mentors does that.  I can drop the rest of the auto-generated files too, if you
like.  Please let know.

-serge