Hartmut Goebel transcribed 2.5K bytes: > Hi, > > following up a discussion from the GNUne mailinglist about how to slice > the software, I would like to learn about the best practice of packaging > huge packages in guix. > > Assume gnuet will be delivered a one big TGZ, inclusing base-libs, > core-services, additional-services, guis for services. For e.g. > RPM-based distros the TGZ would be build once and then sliced into > packages like > > - gnunet(-core) > - gnunet-gns-proxy > - gnunet-fs > - gnunet-fs-gui > - gnunet-conversation > - gnunet-conversation-gtk > > When packaging with guix, one way would be to create several output (fs, > fs-gui, etc.). This would require uses to install e.g. "gnunet:fs-gui" > which is, well, curious for users. > > What is the intened way to solve this in guix?
i think if you want the direct analogy to the thread, as I understand it, we'd get separate package definitions and not separate build outputs. At least my understanding right now is that it could be distributed like this and that downstreams should be able to build from source various small pieces of gnunet. Maybe a 'make dist' could separate it already earlier. But Canonically I think we'd solve this with outputs in guix, at least when you look at git and other, similar applications. The idea is to reduce dependencies, which is then up to Guix to pick the right way. Outputs seems like the wrong approach here at least from upstream perspective. > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > >
