Pau Garcia i Quiles <pgquiles@elpauer.org> writes:

> While working today on Wt again, I've noticed if I were to repackage the
> upstream tarball to remove jquery.min.js, I would also remove the
> Doxygen-generated HTML apidox. After all, I'm also regenerating them,
> therefore to me it's just a few thousands of useless files in upstream's
> tarball. But what's FTP masters stance on this?

I don't think ftp-master particularly cares what additional scrubbing you
do once you have to repackage upstream. If you don't have to repackage
upstream, there's a strong preference that you don't do so, but once you
go down that path, I don't think anyone is particularly concerned with
what else you change provided that it's generally sensible. Either one
can verify checksums with the upstream release or one can't.

I drop the Windows code and the products of upstream's autogen.sh in one
of my packages for similar reasons; it saves a few MB of archive space for
code that's never used in Debian, and I have to repackage upstream anyway,
so why not.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcga1p4c.fsf@windlord.stanford.edu">http://lists.debian.org/87vcga1p4c.fsf@windlord.stanford.edu

â�¦ 23 août 2012 01:01 CEST, Pau Garcia i Quiles <pgquiles@elpauer.org>Â*:

>> I think the debate in this thread is about whether it makes sense to
>> require removing the minimized version from the upstream source when we
>> don't install that file or otherwise use it in the binary package (because
>> the binary package depends on the separately-packaged version of the same
>> Javascript library, which already has both the minimized and non-minimized
>> version and fully satisfies the DFSG).
>
> That's exactly the point
>
> IMHO, it's just one more useless file in upstream's tarball.
>
> While working today on Wt again, I've noticed if I were to repackage
> the upstream tarball to remove jquery.min.js, I would also remove the
> Doxygen-generated HTML apidox. After all, I'm also regenerating them,
> therefore to me it's just a few thousands of useless files in
> upstream's tarball. But what's FTP masters stance on this?

You don't need to reove the doxygen documentation since the source is
also present in the tarball.
--
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)

Bernd Zeimetz writes ("Re: Minified javascript files"):
> On 08/16/2012 08:59 PM, Marco d'Itri wrote:
> > On Aug 16, Vincent Bernat <bernat@debian.org> wrote:
> >
> >> I know this is tedious but what others think about this matter?
> > This is another case in which the DFSG has become a religion to be
> > followed in a literalist interpretation instead of a tool to be used
> > for the purpose of advancing software freedom.
>
> I rarely share Marco's opinion, but this time I do.

I agree. There are good reasons for being cautious about non-free
stuff in source packages, but the way we do things now is pointless
make-work.

Better would be if we could teach dpkg-source to remove undesirable
things, present in the original source tarball, from the unpacked
source tree. Then they wouldn't be distracting/confusing and there
would be no risk of using them by mistake but we wouldn't have to prat
about rebuilding archives which might otherwise remain pristine.

Doing it this way would also prevent accidental reintroduction of the
undesired files into the source tree visible to Debian, which can
happen if someone uploading a new upstream version forgets to launder
the upstream source.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20535.29144.610789.729724@chiark.greenend.org.uk"> http://lists.debian.org/20535.29144.610789.729724@chiark.greenend.org.uk

Raphael Hertzog writes ("Re: Minified javascript files"):
> I agree with you that it's useless work. But the ftpmasters believe that
> Debian is made of source and binary packages and that the content of the
> source package should respect DFSG #2 “The program must include source
> code[...]�.
>
> Maybe we should fix DFSG #2 to say “The program must include source code
> for all the files that gets installed in the Debian binary packages [...]“.

I don't think this should be fixed by changing the DFSG. The DFSG is
correct - sourceless minified js files, GFDL docs with invariant
sections, gimp-generated pixmaps without the original gimp source,
etc., are all Not Free Software.

The question is simply a practical one: is it actually worth our while
to repackage upstream sources to remove unused non-free (but
redistributable) elements. Who does this benefit ?

If it enhances anyone's freedom (or to put it another way, if failing
to do it would risk harming anyone's freedom) then that would be a
good reason to do it, but at the moment I don't see where that risk
comes from. The effect is just to make us do work.

The main objection, it seems to me, to the presence of these files is
that removing them is the only sure way to make sure that the actual
package build doesn't use them somehow. But that objective could be
met by some kind of filtering by dpkg-source at unpack time.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20535.29720.103031.195954@chiark.greenend.org.uk"> http://lists.debian.org/20535.29720.103031.195954@chiark.greenend.org.uk

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I don't think this should be fixed by changing the DFSG. The DFSG is
> correct - sourceless minified js files, GFDL docs with invariant
> sections, gimp-generated pixmaps without the original gimp source,
> etc., are all Not Free Software.

I agree entirely with that paragraph.

> The main objection, it seems to me, to the presence of these files is
> that removing them is the only sure way to make sure that the actual
> package build doesn't use them somehow.

That is one which has been discussed. I don't think it's the most
compelling one though.

It seems to me that the primary objection to the presence of these files
without source is that they are then distributed as part of Debian, in
the source package. That violates our social contract.

This objection is unrelated to what our build process does with those
files, or even whether the build process ignores them. By remaining in
the source package, we are distributing them as part of Debian.

Upholding the social contract – that Debian, as distributed by the
Debian project, remain 100% free – is sufficient reason to remove these
files without corresponding source.

--
“Isn't it enough to see that a garden is beautiful without |
` having to believe that there are fairies at the bottom of it |
_o__) too?� —Douglas Adams |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k3wng29r.fsf@benfinney.id.au">http://lists.debian.org/87k3wng29r.fsf@benfinney.id.au

Ben Finney <ben+debian@benfinney.id.au> writes:

> It seems to me that the primary objection to the presence of these files
> without source is that they are then distributed as part of Debian, in
> the source package. That violates our social contract.

The counter-argument from affected maintainers is that we *do* have the
source. It just happens to be in a different source package. We even
know that, because when we build the binary package we use the version of
the Javascript library derived from that other source package.

There is therefore no *actual* violation of the social contract here, just
an inadequacy of bookkeeping.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipc7ra6q.fsf@windlord.stanford.edu">http://lists.debian.org/87ipc7ra6q.fsf@windlord.stanford.edu

On Aug 25, Ben Finney <ben+debian@benfinney.id.au> wrote:

> Upholding the social contract – that Debian, as distributed by the
> Debian project, remain 100% free – is sufficient reason to remove these
> files without corresponding source.
As I said, this is a religious argument.
It's OK, billions of people have a faith and your one appears to be
literally following the DFSG.
But let's not pretend that this in some way helps software to be more
free, because it does not.

--
ciao,
Marco

md@Linux.IT (Marco d'Itri) writes:

> On Aug 25, Ben Finney <ben+debian@benfinney.id.au> wrote:
>
> > Upholding the social contract – that Debian, as distributed by the
> > Debian project, remain 100% free – is sufficient reason to remove these
> > files without corresponding source.
> As I said, this is a religious argument.

You'll need to explain better what you mean, then, because the argument
makes no reference to any supernatural entities.

> It's OK, billions of people have a faith and your one appears to be
> literally following the DFSG.

I don't know why you bring faith into this.

--
“Nothing is so common as to imitate one's enemies, and to use |
` their weapons.� —Voltaire, _Dictionnaire Philosophique_ |
_o__) |
Ben Finney

md@Linux.IT (Marco d'Itri) writes:

> On Aug 25, Ben Finney <ben+debian@benfinney.id.au> wrote:
>
> > Upholding the social contract – that Debian, as distributed by the
> > Debian project, remain 100% free – is sufficient reason to remove these
> > files without corresponding source.
> As I said, this is a religious argument.

You'll need to explain better what you mean, then, because the argument
makes no reference to any supernatural entities.

> It's OK, billions of people have a faith and your one appears to be
> literally following the DFSG.

I don't know why you bring faith into this, if not as a vague smear
without addressing any points.

--
“Nothing is so common as to imitate one's enemies, and to use |
` their weapons.� —Voltaire, _Dictionnaire Philosophique_ |
_o__) |
Ben Finney

On Fri, Aug 24, 2012 at 07:13:01PM -0700, Russ Allbery wrote:
> The counter-argument from affected maintainers is that we *do* have the
> source. It just happens to be in a different source package. We even
> know that, because when we build the binary package we use the version of
> the Javascript library derived from that other source package.
>
> There is therefore no *actual* violation of the social contract here, just
> an inadequacy of bookkeeping.

Agreed, which is why I too find Ian's proposal interesting.

The problem I see with it, is that it adds complexity to the judgement
of whether something is suitable for a source package or not (on all
actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With
something like that we'll have 3 cases:

- DFSG-free source[1] -> stay in the tarball, not hidden
- non DFSG-free "binary" -> must be removed, via repacking
- "binary" generated from DFSG-free source available elsewhere in the
archive -> stay in the tarball, hidden at the dpkg-source level

This is quite a bit of extra complexity. And it would require
documenting not only that something is being removed at the dpkg-source
level (the dpkg-source configuration file for the removal feature would
suffice), but also documenting where the corresponding source is.

Another problem is that the DFSG-freeness of the material contained in a
(source) package is no longer a "local" property. If one day the package
containing the corresponding source vanishes from the archive, unrelated
packages, possibly many of them, will become RC-instabuggy.

On the positive side, the proposed dpkg-source exclusion feature is
interesting in its own right, to ensure that something included in the
tarball does not interfere with the build process, as already mentioned.
(Yes, that could be achieved in debian/rules via "rm" invocations, but
having a declarative way of doing so would be preferable.)

Cheers.

[1] in the sense of "preferred form of modification"
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »