I have been thinking about adding Debian-package-fetching functionality (tentatively named fetchapt) into nixpkgs, and I'd like to hear your thoughts.
First, why would anyone want such a thing? Nixpkgs retrieves some unfree software (e.g., google-chrome) through binary packages in Debian packaging format, through vendor repositories (e.g., dl.google.com). Currently, retrieving the binary packages involves manually specifying package version number and hash value in a nixpkg. This approach has a few advantages; for example, users can look at nixpkg and determine exactly which version of the software is being installed. Also, nixpkg can verify use the hash value to confirm that the binary package has not been tempered with. This approach also has a major downside. Someone needs to update the version number and hash value manually every time there is a new release. Which can be a lot of work for software with frequent releases, like Chrome. Right now, the stable version for Chrome Linux is 54.0.2840.71, and nixpkg is still pinned to 53.0.2785.143, which is one major version (and ~20 security vulnerabilities) behind. And the ability to pin software to a specific version is not all that useful here. Once the vendor makes a new release, the old version may no longer be available in the vendor repository. And users expect to be able to install new versions when they become available without having to wait one of the (wonderful) Nix devs to update some strings somewhere. Adding support for fetching binary packages in Debian format from an APT repository would solve this problem. I envision that a nixpkg would specify: - the APT repository base URL - the release name (e.g., stable, testing, or unstable), - the binary package name, - repository signing key (for repositories that implement secure APT, https://wiki.debian.org/SecureApt). And the fetchapt derivation would: - Fetch Release and Release.gpg files from the repository - Verify digital signature - Fetch Packages file - Check hash value of Packages file against the hash value listed in Release file - Extract binary package path that correspond to the given package name from Packages file - Fetch the binary package - Check hash value of binary package against the hash value listed in Packages file So nixpkg will automatically follow upstream vendor releases without any action from Nix devs. Even though nixpkg does not directly contain a hash value of the binary package, secure APT will provide strong assurance that users are receiving a binary package exactly as provided by the vendor. Anyway, that is my proposal. Does that sound like a reasonable thing to do? How would such a functionality fit into nixpkgs? Any advise or suggestions on design and implementation? Thanks, and looking forward to hear your thoughts. Chuan-kai
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev