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

labs at parabola.nu labs at parabola.nu
Wed Jul 31 17:15:33 GMT 2019

Issue #2403 has been updated by bill-auger.

are you suggesting not to host any sources, or to continue
hosting the pristine upstream sources warts and all? - that is
the most important concern, regardless of what the tools do

probably the original intention was that users should never need
to download known non-free software; and to avoid publishing any
tools that automatically do so - on the one hand, that would be
even worse than what TPPMs do in terms of suggesting and leading
users toward non-free software - on the other hand, i think we
agree that this particular use-case is not "for practical use" ;
so it may not be a strict FSDG requirement - if the source-balls
are not clean though, as must be the case if they are created
before prepare() runs, then PKGBUILD with the mksource() function
are the only ones that produce pre-cleaned sources - everything
in [libre] should have had that same treatment; and perhaps that
was the goal - if nothing else in [libre] gets that treatment,
then those few are just a drop in the bucket; and moving the
mksource() procedure into prepare() for those few package which
have it, would be barely significant to the big picture - that
would be the easiest way to resolve the present issue; but its
not a very satisfying solution

if the suggestion was not to host any sources, the biggest
concern i have with that is the obvious one - im not sure if the
FSDG requires that; but it does require that we ensure all source
code to available for the current release; and the only way to
ensure that is to self-host it - that would make source code
storage to be essential infrastructure; and it is always unwise
to rely on third-parties to maintain your essential
infrastructure , especially with no contract - regardless of the
FSDG, the GPL alone extends that requrement to three years
beyond the current release, for GPL programs - the only
third-party code host that i would be comfortale using for that
purpose would be the software heritage repos - i think they are
a legitimate charity, so they do have some obligation to the
public - that can not be said of most individual projects or any
commercial freebie hosts; but it would be a lot of work to
change every PKGBUILD to fetch from that host - also, i dont
think they prioritize tracking the bleeding edge of changes; so
that cuod be a no-starter for parabola

aside from ensuring that sources are somehow available, there is
the FSDG "self-hosting" requirement; according to which, one
should be able to compile vN+1 of the distro using only vN of
the distro and tools that are provided by the distro - i dont
think that ubuquitous networking should be taken for granted as
an excuse to avoid supplying everything required to build the
distro - software curation is the one defining factor of what a
distro is and what distro devs do - ideally, i would like to
take that a step further and publish a sources ISO for
offline/clean-room use - currently, a user would need to do an
unreasonable amount of prep work, if they wanted to accomplish
that; but we already have most of the tooling to make that a

im pretty sure that is why parabola mirrors everything from
arch, rather than having users rely solely on the arch repos -
some users are very concerned about to which servers they expose
their IP - i would like to take that concern a step further and
modify the redirector to always use a parabola mirror - if
winston had a gigbit pipe with unlimited traffic, we could
remove the redirector entirely - the redirector is a necessary
compromise due to circumstances, in a similar way as relying on
the upstreams to feed the user facing PKGBUILDs; but we do have
the resources to avoid the latter because of the lesser damand
for source-ball 

i think that complete self-reliance was a goal of the project
that is still incomplete; so if we need to modify libretools, i
would rather continue in that direction rather than removing
relevent functionality - i like the idea of downloading from the
upstream and running prepare() in memory, then creating the
source-ball after prepare() has done its work; resulting in a
cleaned tarball on the local filesystem - librestage and
librerelease already are expecting that libremakepkg has created
one - the only real problem with the current workflow is that the
source-balls are not clean and the VCS ones are overweight - the
latter can be solved simply by rm -rf the VCS data dir
(.svn/, .git/, .hg/)

an alternative idea, which i like better, would be to put those
pre-cleaned source-balls into use by modifying makepkg to
recognize, according to $pkgname-$pkgver, that a pre-cleaned
source-ball exists on the parabola server and to pull that
instead of the upstream sources, bypassing the prepare()
function - if no pre-cleaned source-ball exists for that
version, then that is unsupported software, just like AUR, and
falling back on the upstream sources is the reasonable thing to
do - as with the AUR, we could suggest against doing so "for
practical use"; but endorese it only for the use-case of helping
parabola devs liberate it "for practical use" by others

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

* 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

More information about the Dev mailing list