[Pkg-shadow-devel] out of my depth

[Serge E. Hallyn]

On Thu, Dec 01, 2016 at 02:57:13PM +0100, Bálint Réczey wrote:
> Hi Mike,
> 
> 2016-12-01 8:25 GMT+01:00 Mike Frysinger <vapier at gentoo.org>:
> > On Tue, Nov 29, 2016 at 6:45 PM, Bálint Réczey wrote:
> >> 2016-11-27 9:02 GMT+01:00 Mike Frysinger:
> >>> 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:
> >>>> > 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.
> >
> > i have no opinion at all how Debian wants to maintain their .deb sources
> 
> This thread was about that question.
> 
> >
> >> Reviewing changes when autogenerated files pollute the diff is harder
> >> and shadow is an important package.
> >
> > yes, but as a general thing, always rebuilding autotools from scratch
> > is kind of wasteful and can be a pain when the sources aren't kept up
> > to date (and you try to use newer autotools which have new
> > warnings/errors).  i'm not familiar with how Debian typically builds
> > things though, so maybe that's "normal".
> >
> >>> 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?
> >
> > forcing all users of shadow to build autotools from scratch is
> > fundamentally wrong.  it defeats the entire purpose of autotools.  if
> > *you* don't want to use them, then fine, don't, but Debian is not the
> > entire ecosystem.
> 
> Please open an issue at upstream if you really need ./configure
> generated for you:
> https://github.com/shadow-maint/shadow
> 
> >
> > make sure you don't conflate "what's good or makes sense for Debian"
> > with "this is standard open source release behavior".  while the
> 
> Vast majority of the GitHub projects only tag their releases and let GitHub
> generate the tarball for releases. I would prefer having those tarballs signed
> but I don't miss the pre-generated files from them. It seems this is the new
> standard and I'm happy with that.
> 
> > shadow upstream git repo is utilizing Debian infra now, it doesn't
> > mean the shadow sources and release behavior should be specific to
> > Debian.
> 
> Upstream repo is on GitHub. The mailing list can stay on alioth but I
> would prefer
> the old outdated home page to be retired or updated with accurate information.
> 
> I think the the cleanest solution would be keeping the mailing list
> for packaging

Would it be appropriate to request a vger.kernel.org mailing list for shadow?

Nice and vendor-neutral.

> discussions and moving all upstream activity to GitHub.
> 
> The svn repo is not active, it should be set to read-only, too, IMO.
> 
> Cheers,
> Balint