On 2017-08-06 17:24:59 -0400 (-0400), Ondrej Novy wrote:
> Lintian considers this as "bug":
> https://lintian.debian.org/tags/source-contains-prebuilt-sphinx-documentation.html
> (pedantic, I know).

I'll can't help but ponder why lintian should have _pedantic_
opinions on upstream tarballs. Policy violations from upstream, yes;
being picky about contents of the debian dir, sure; but nit-picking
what's in an otherwise DFSG-compliant upstream tarball? I guess it's
so you can let upstream know in case they might have made a mistake
in their release process, but the obsession from some (particularly
new) maintainers with making their packages lintian --pedantic clean
makes me suspect this does more harm than good in the long run if it
encourages them to needlessly filter and repack just to silence the
most benign of low-level warning messages.

> But they want to keep generated (read: useless for our orig tarballs)
> things inside release tarballs.

Well, OpenStack release tarballs don't include HTML documentation in
the sdist anyway so this is a bit tangential to the thread, but I
for one will happily put my weight behind solving whatever issues in
those tarballs actively prevent Debian from being able to use them.

> And sdist orig tarballs are too big, because they contains
> prebuild things, FTP masters are not happy. (Thomas words).
> Context:
> http://lists.alioth.debian.org/pipermail/openstack-devel/2017-July/021447.html
> ... I've been already flamed by the FTP masters because small
> packages like nova-compute-* became insanely huge (ie: megs instead of
> kbytes). ...

Thomas references the AUTHORS and ChangeLog files (which embed
important metadata from the revision control system into the release
tarball, far from useless in my opinion); but taking the
nova-15.0.0.tar.gz release for example, those two files account for
a total of 5% of the unpacked tree according to du and probably
compress fairly well. By comparison, the unit tests and fixtures
make up 42% of the size of the tree on their own. He's also
referring to a situation from _years_ ago, which was subsequently
changed after he asked... those current tarballs only include author
names and very abbreviated information parsed out of the git log and
have been that way since 2013 (pbr commit 94a6bb9 released in 0.6),
but mentioning that would likely have undermined his argument.

It's the charge of the FTP masters to push back and ask questions
when they see something they think may be in error, and the
responsibility of developers to fix things OR explain the situation
to their satisfaction. I'm unsurprised they raised an eyebrow at the
size of the old nova changelogs, and this was addressed upstream as
a serious concern (I was heavily involved in the work to make that
happen, and glad to do it). As I said, I will personally invest
substantial effort to remove roadblocks in the way of any Debian
maintainer's use of whatever OpenStack release artifacts would serve
their workflows best, but I much prefer to base decisions on where
to spend my time on factual data rather than vague assertions which
may no longer be relevant.

> I consider git repository to be better source of "source code"
> than sdist, which is built from that same git. But it's just about
> POV :).

I know others share that opinion too, but as above if I `apt-get
source nova` the unpacked tree doesn't provide me with information
on who the upstream authors are, nor a detailed changelog of how it
differs from prior releases... and no way to build that information
from the tree. This seems to me like important information a user
might care about as a recipient of the source code. I get that most
users who want that will probably have access necessary to git clone
the repo, but Debian also isn't about just satisfying the majority.

It's your prerogative as a package maintainer to use your best
judgement and choose whatever workflows suit you, obviously. I
simply want to make sure that OpenStack (or any other project I
contribute to for that matter) gives distros flexible options, and
that you base your decisions as to what to use on research and fact
rather than hearsay.
Jeremy Stanley

Attachment: signature.asc
Description: Digital signature

Reply via email to