"Jason Self" <[email protected]> skribis: > Ludovic Courtès said: >> I'm reluctant because of the technical and administrative burden it >> entails > > I suppose another option is to leave out problematic packages > entirely. Otherwise, welcome to the world of being an FSF-endorsed > distro. :)
Well the FSDG don’t go this far, or least not at this level of detail. >> Besides, our package meta-data would probably still refer to the >> "real" home page of the package, from which it's trivial to get the >> unmodified tarball. > > I think the question isn't whether or not the users of a distro can > leave their distro's infrastructure and install non-free or other > programs on their own. Rather, it seems more a question of if the > programs that the users finds through the distro are themselves > FSDG-compliant [0]. The user interface for Guix is the ‘guix package’ command. That command will only ever give you FSDG-compliant packages. What we’re really talking about it here is *how* it gives those packages. > I agree with what Sam said regarding Parabola back in 2011 [1] that: > >> Consider that the software is really the source code and that the >> binaries are just the usable machine-readable form of it. Both >> source code and binaries should be free (the latter follows from the >> former if all is well). Of course, I can only agree with that. But, what does “source code” mean here? Does it mean the source that’s made available using the distro tools, such as ‘apt-get source’? [...] > Ludovic Courtès said: > >> we'd need an out-of-band mechanism to maintain patches/scripts, said >> patches/scripts would have to be reviewed separately, contributors >> would need to have the necessary credentials to upload patched >> tarballs, etc. > > I think some of this can be automated and minimized. Trisquel, for > example, uses what they call Helpers [2]. As new versions are pulled > in from Ubuntu the corresponding package helper is run, if one exists > for that package. That helper is responsible for making any changes > that are needed to the source code and repackaging it before it is > moved into the Trisquel repositories to be compiled. In this way the > users of the distro always have access to FSDG-compliant source code > packages. OK, interesting. What kind of changes are these, typically? Are these changes to debian/ files (such as adding new patches), or are these changes outside of the debian/ directory? > Is there some automated method in which Guix checks for new versions > from upstream? Yes, but limited to GNU packages ATM: http://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-refresh > Perhaps this could be extended such that, for certain programs, > they're run through some script to clean them up in a similiar > automated fashion to Trisquel? The gnupload script [3] could then be > used to upload them to, say, the GNU FTP server? (Perhaps in the > non-gnu area?) In this way the process that checks for new versions > handles the actual work. People contributing to Guix only need access > to the version control system to maintain the "helper" for that > program. Right, possibly. Food for thought... I think what should be clarified is what we want to achieve exactly. Currently, users can only install FSDG-compliant software. However, ‘guix build --source’ [0], which is really a developer’s tool, returns the unmodified upstream version. So, do we want ‘guix build --source’ to return the already-patched, FSDG-compliant source? Or do we want to go further, and where? Thanks for your input! Ludo’. [0] http://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-build
