[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spliting a huge package

From: ng0
Subject: Re: Spliting a huge package
Date: Thu, 7 Feb 2019 19:14:06 +0000

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

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          | address@hidden               |
> | | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]