[Dev] [libretools - Feature Request #2403] [libremakepkg]: eradicate mksource() from abslibre

[labs at parabola.nu]

Issue #2403 has been updated by eschwartz.


The concept of "libre" tarballs is essentially the same concept as Debian's "orig" tarballs, where an upstream source release artifact is taken, but the distro decides it isn't "good enough" and determines to apply certain changes. In debian's case, that sometimes includes deleting lots of files that maybe aren't used by the package, for example if software contains a vendored copy of a library, with a configure switch to either use the vendored copy or a system copy... Debian might delete that. Debian might delete minified js from the source tarball. Debian might rename the directory it is stored in, Debian might just recompress the tarball so its checksums don't match but it takes less space on their mirror network.
https://www.debian.org/doc/manuals/developers-reference/ch06.html#repackagedorigtargz

The question is why this is necessary. Debian certainly seems to think it is so, but then, Debian hosts the sources for every package, no matter what. They also seem to be going to some lengths merely for the sake of prettiness.

Does the DFSG truly require you to not make noncompliant source code available at all? If all you are doing is providing a persistent mirror of the upstream tarball, but the canonical "help" that Parabola offers, guiding people towards the act of building and installing the software, is the PKGBUILD, then the PKGBUILD -- regardless of the state of the sources themselves -- does not encourage using non-DFSG software. The PKGBUILD will, when left to its own devices, always build a DFSG-compliant binary product, and extracting the build information but removing the DFSG bits is not a supported or recommended route.

>From my outside perspective, it would seem like Parabola should have the option to just upload mirrors of the tarball, but have the PKGBUILD perform all DFSG compliance modifications in prepare() -- with suitable comments saying "# these changes, in accordance with the DFSG, protect the user by removing nonfree software".

The alternative is to make it difficult to use the PKGBUILD at all, causing users who want to use the PKGBUILD as a base for updating the version to give up and download something from Github or another upstream website and run ./configure; make; sudo make install without the benefit of a PKGBUILD or DFSG modifications.

----------------------------------------
Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre
https://labs.parabola.nu/issues/2403#change-12683

* Author: bill-auger
* Status: info needed
* Priority: discussion
* Assignee: 
* Category: 
----------------------------------------
related to forum thread https://labs.parabola.nu/boards/18/topics/125

IIRC when discussing the 'ruby' package, we concluded that it was probably intended per the FSDG, to provide complete and pre-cleaned source-balls to the distro users; which entails the devs to keep some of the libre-fications tools private

the FSDG does not require support for versions of 'foo' that were not included in any distro release however; but OTOH, this PKGBUILD contains instructions for downloading known non-free software

on the third hand (the philosophical hand), the 'gist' of the four freedoms is not about possessing or sharing non-free software; but that the user is able to do with it as they see fit - if the only thing that one wishes to do with that software is to merely posses it or share it, then anything redistributable would satisfy the 'gist' of the four freedoms for that person

probably the simplest way to resolve this class of issue, is to add a note to the PKGBULID with sed above every instance of 'mksource()', asking the reader to ignore it and ask a parabola dev to publish the intermediate source-ball, if they are building ahead of the current release; then to publish the missing source-ball for any enthusiastic user who asks for one - a better solution to this class of issue, would be for the PKGBUILD to explaining how to run mksource() and have the mksource() function create the source-ball with expected libre name in the sources() array - if that does not conflict with the FSDG - an even better solution to this class of issue, is to eliminate it by eradicating mksource() from abslibre somehow, even if that is simply moving the PKGBUILD to a private git branch

this incident is not a peculiar though - it is currently systematic AFAIK; so i consulted the FSDG:

  "A free system distribution must not steer users towards obtaining any nonfree information
for practical use, or encourage them to do so. The system should have no repositories 
for nonfree software and no specific recipes for installation of particular nonfree programs."

there is another clause that might suggest that this use case is within the guidelines; although it is in the "Documentation" section

  "In general, something that helps people who already use nonfree software
to use the free software better with it is acceptable,
but something that encourages users of the free software to install nonfree software is not."

libre-fications would seem to fit into that documentation exception - id say the key point is that such scripts do not install the program "for practical use" - the use-case in which the user is interested, is to download a non-free tarball, and to liberate it, without viewing or executing any of the files within it; for the sole purpose of using the cleaned sources in freedom - it would seems better to instruct people how to liberate non-free software rather than impeding their curiosity or ambition; though it may snag upon some FSDG caveat 

some options:

* should consult the FSDG mailing list about this grey area
* put these on the wiki as documentation, instead of in PKGBUILDs
* libretools could be made to download the file into memory instead of writing a hard copy
* hide all such scripts at the cost of impeding enthusiastic users who want to help




-- 
-- ^^ Type your reply above this line ^^ --
-- Please keep the 'Subject' as it is    --

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account