Issue #2403 has been updated by bill-auger.
freemor wrote: > > Going the other way would require us to strip steps out of > prepare to move them into mksource() for every package we > build. well not every package; but every one that replaces something in arch - the parity with the arch PKGBUILDs could still be maintained that way - only the "librefication" commands would need to be in mksource() - doing so could actually make the diffs cleaner than they are now freemor wrote: > Since we probably don't want to re-write makepkg, the > problem with this is we then have a clean source that the > PKGBUILD may fail to build yea thats my thinking - any changes from the current workflow would entail some modification to makepkg - at least we understand now why mksource() exists - it just was not fully utilized for every package; probably because it is such a huge take freemor wrote: > People coming from Arch are going to be confused if the usual > pull the PKGBUILD, run makepkg approach fails. makepkg would not fail with the current workflow because the cleaned tarballs are published at the location where the PKGBUILD expects them to be - as i understand, the mksource() function only runs if that tarball is not found on the server freemor wrote: > Trying to debug from pre-cleaned > sources could be problematic too thats certainly true; but simply changing the URL of the expected cleaned source-ball in the sources array would force mksource() to run again - AFAIK the newly generated source-ball only gets published upon librerelease freemor wrote: > a.) complicate things. > b.) kick the unclean source further down the road. i dont think mksource+librefetch: would be "complicated" - it would just be a shit-ton of work to sort the librefication commands out of prepare() and into mksource() for every libre package; but presumably the tools already have that functionality to handle it what would be complex is modifying makepkg to create the tarball after prepare() has run, and to skip over prepare() if pre-cleaned source-balls are detected - if we were writing makepkg from scratch, i think that would be most reasonable from the engineering perspective; but it is a significant deviation from arch; but going to be the case no matter how this is done approach B would surely be less work; but that is a deviation from the arch tools also - approach A has the added advantage of making the diffs against arch much cleaner for evermore into the future if librefetch does its magic transparently, without manual steps, it probably is the best approach as a long-term investment * the deviation from arch is constrained to libretools * the tooling already exists and is working well for hyperbola * cleaner diffs * users who run libremakepkg on versions ahead of parabola will get a cleaned tarball ---------------------------------------- Feature Request #2403: [libremakepkg]: eradicate mksource() from abslibre https://labs.parabola.nu/issues/2403#change-12952 * 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 _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
