Spliting a huge package

Spliting a huge package

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 935 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?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Spliting a huge package

[ng0]

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.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

Re: Spliting a huge package

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> 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.

For Git we have a bunch of different outputs, which works well but is a
bit weird for users.

In other cases, we have “-minimal” variants and a regular, full-featured
variant.

There are also cases like Octave where there are several packages.

So I guess it really depends on what the split involves technically and
how it affects actual usage.

Thanks,
Ludo’.