Additional binary caches for unusual flags

[Pitometsu]

There a lot of widely used variants for lots of packages, like support of gtk, qt, jack, pulseaudio, or even if I choose unusual option for package like ffmpeg, a lot of packages build from sources then.

This's feature request.

---

So I propose to auto-generate custom names for packages with various variants like emacs-with-gtk3-depend-on-ffmpeg-with-lame, put them to all-packages.nix to force hydra build binary versions for them. And make additional binary caches for such stuff similar to Arch Linux's AUR.

[Pitometsu]

Surely, it's not so good to hardcode all the dependencies variants in package name. So is there any ideas for better solution (not implying to build whole the system from sources each time)?

[Pitometsu]

Most annoying is big packages like firefox, chrome, libreoffice. And packages that are dependencies of lots others, like qt, gtk, ffmpeg, pulseaudio, jack.

[peti]

It would be be great if you could make a specific suggestion what to add, i.e. in the form of a PR?

[vcunat]

It's nixpkgs policy to minimize the number of such combinations, at least wrt. what is encouraged and built on Hydra. Most distributions do that as well, and IMO there are good reasons for that.

There are still likely to be some particular combinations that are worth adding, but I don't think it would be cases like foo-with-ffmpeg3 and foo-with-ffmpeg2.

[joelmo]

I think there already are too many ways to specify a custom package. One is using callPackage. Another way is to use hello.override. Many packages use the style with argument supportXxx, this way you can set your override top level in your config.nix to be supportXxx = true and automatically get customization. There is some here PR that discovers such arguments.
I hope it is possible to implement the module system for nixpkgs so that documentation of such options can be generated and discovered easier. It will probably need some additional function or system to define the scope of such supportXxx settings. I am happy with this system in NixOS and think it could work for nixpkgs. I am not using much custom packages here, mostly because it would require me to wait longer when upgrading packages. With additional binary caches this would maybe be different.

[Pitometsu]

of such options can be generated and discovered easier

It would be great!

it would require me to wait longer when upgrading packages.

Yeah. It's a main disadvantage: just few custom options and you forced to wait a lot till the whole system will build from sources. Currently there progress with qt5, as I know (ability set qtGtkStyle for qt5 applications without recompilation).

Not sure how, but this somehow done in binary-based distributions (each flag implemented by little separate package).

[Pitometsu]

But users with such option anyway compile that packages locally. So there just need ability to upload those packages to some cloud storage like Arch's AUR repository. Because of hashes all packages already will be signed.

[Pitometsu]

Also (just a little other question): is there ability to cross-compile packages (e.g. on power amd64 compile packages for arm device)?

[joelmo]

There is a little discussion here how to improve package variations: #16531

[vcunat]

So there just need ability to upload those packages to some cloud storage like Arch's AUR repository.

We might best add a P2P service and substituter, e.g. via IPFS NixOS/nix#859. It would likely need a substantial amount of work, unfortunately.