Pjotr Prins <pjotr.publi...@thebird.nl> writes: >> I don’t think this should be the only mechanism through which people can >> provide channels. I wouldn’t want to have to essentially fork Guix. >> For a user this is a problem, too, because channels would no longer be >> composable (today I can compose multiple package collections with >> GUIX_PACKAGE_PATH). > > I am not sure composability is required for most use cases. I think we > should keep it simple. I am happy to have channels act independently > if we can get it this year.
Yes, it’s not a big feature as there are practical limits to composing multiple channels. However, simple composition can come in handy. At the MDC, for example, we strictly separate non-free software from free software variants that are not available in Guix upstream. Users can add one or both of these package repositories. This would not be easy with the proposed “Guix fork as channel” implementation. That said, I think that having a more featureful “guix pull” is a good goal in itself. Even better if this happens to scratch your itch wrt channels already. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
