"Thompson, David" <dthomps...@worcester.edu> skribis: > On Thu, Apr 14, 2016 at 10:28 AM, Ricardo Wurmus > <ricardo.wur...@mdc-berlin.de> wrote: >> >> Thompson, David <dthomps...@worcester.edu> writes: >> >>> On Thu, Apr 14, 2016 at 9:51 AM, Hartmut Goebel >>> <h.goe...@crazy-compilers.com> wrote: >>>> Hi, >>>> >>>> today on irc, there was discussion about that Guix should be easily >>>> installable and manageable in other distros being higher priority. This >>>> could attract more users to ry out Guix. So I created a draft .spec-file >>>> for building and installing Guix o RPM-based systems like Fedora. >>>> >>>> Maybe someone using Fedora may want to add a package request in their >>>> bug-tracker. I already did for Mageia. >>> >>> This has come up several times, and I agree that we should provide >>> packages for popular GNU/Linux distributions. However, Guix *cannot* >>> be made available in many distros official repositories (most notably >>> Debian and Fedora) because Guix violates their policies, such as: >>> >>> - Software must conform to the Filesystem Hierarchy Standard >>> (violation: Guix introduces the /gnu directory) >>> - Software must be bootstrapped from source (violation: Guix requires >>> a set of bootstrap binaries that *cannot* be replaced by the distro >>> without changing the hashes of every package, effectively preventing >>> them from receiving binaries from hydra.gnu.org) >>> >>> Guix is at odds with other distros because it is a distro itself. So, >>> I think what would be best is for users of these distros to host Guix >>> packages in popular places for third-party packages, like Arch's AUR >>> or Fedora's COPR: >>> >>> https://aur.archlinux.org/packages/guix/ >>> https://copr.fedorainfracloud.org/coprs/lantw44/guix/ >>> >>> What would be even better is if people *told us* when they made a >>> package. I learned about these indirectly, long after they were >>> originally available. >> >> Could we add the .spec, PKGBUILD, and debian files to the Guix >> repository? I know of many projects that include the package manifests >> to simplify building packages for major distributions. >> >> An advantage would be that we knew about these files and users wouldn’t >> have to search around for the latest package sources. > > That sounds like a good idea. I would welcome patches for such things.
Seconded (as long as it’s one or two files per distro.) Ludo’.