[Pkg-shadow-devel] out of my depth

[Mike Frysinger]

On Thu, Dec 1, 2016 at 8:57 AM, Bálint Réczey wrote:
> 2016-12-01 8:25 GMT+01:00 Mike Frysinger:
>> 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.

no, this thread was about including gmo files in the dist tarball.  it
then spiraled into the weeds with people giving bad advice for how to
do a release.

>>> 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

opening a bug report for an issue that can't be solved by a
creating&pushing a commit won't help.  the release process here is
broken and that's external to the code in git.

>> 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.

you've provided no data to back this up.  however, even if the
"majority of projects" do this, it doesn't mean those projects are
using a build system (e.g. autotools) where the diff matters.  for
autotools-based projects, it is extremely uncommon to do what you're
suggesting.  when it has happened in the past, it was usually a
mistake or overlooked, and the respective project fixed their
processes.

the entire point of autotools is to *not* have to download perl,
autoconf, automake, gettext, libtool, etc... onto the end system to
actually compile the project.  if you think it's OK to force that onto
users, then i don't think you have real world distro experience
supporting this on the scale of decades across 10s-of-thousands of
projects.  i do and i know first hand it doesn't work.  distros
frequently do not ship the very latest autotools versions, especially
in the LTS world, so a project requiring like autoconf-2.70+ would
become unavailable quickly.  or dealing with a code base where
autoconf-2.70 changed a warning to an error and now all your old
releases can't be built.  both of these scenarios are common.

if you/Debian/whoever wants to deal with that pain, then that's their
prerogative.  but shadow as a vendor neutral upstream should not be
screwing this up on purpose.

nowhere did i say "only do pregenerated releases".  once a tag is
pushed to GH, you get that automatic tarball generation, and you can't
turn it off.  just because you upload a tarball created from `make
dist` doesn't me that other tarball goes away.  you can still easily
fetch:
  https://github.com/shadow-maint/shadow/archive/4.4.tar.gz
or you can fetch:
  https://github.com/shadow-maint/shadow/releases/download/shadow-4.4/shadow-4.4.tar.gz

now you get to pick your poison.

>> 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.

i don't think that was announced anywhere.  just suddenly a GH mirror
of shadow showed up, and things sometimes happened there.

> The mailing list can stay on alioth but I

i don't think anyone cares where the mailing list is hosted.

> would prefer
> the old outdated home page to be retired or updated with accurate information.

agreed the website should get moved.  if it exists on GH too, we can
bounce everything to https://shadow-maint.github.io and people can
send updates/PRs like normal.

> I think the the cleanest solution would be keeping the mailing list
> for packaging
> discussions and moving all upstream activity to GitHub.

i have no opinion on that.
-mike