Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 20:00 +0200 schrieb Maxime Devos:
> That's one method for faster builds, but you'll get even faster
> builds by also making union-build O(n lg n) instead of O(n²), and the
> latter optimisation will help everyone and not only Guix Home users.
If that's what you want then go ahead and improve union-build.  Unless
you add some serious waste that eats up thousands of cycles if supplied
with no more than three packages, I doubt it has any serious effect on
my analysis that small n = better.

As for the complexity of the actual implementation, I'm pretty sure
you'll find it to be n log n in most cases, but I also fear that there
might be degenerate cases in which the fact that we're reporting errors
at all leads to a worst case lower bound of O(n²). 

> And the O(n)=O(1) doesn't seem quite right here to me -- individual
> profiles will be smaller and hence faster, but there will also be
> _more_ profiles.  Maybe if you sum over the profiles, you'll get to
> O(n) instead of O(n²) (where n = number of store items in the
> profiles)
Again, k(n log n) <= nk log nk, for k >= 1.

> But this doesn't take in account the _user_'s time cost of
> having to figure out some kind of thematic split that doesn't break
> search paths.
And you're not taking into account my time cost of debating you when I
already have manifests split across many files that I want to manage as
separate profiles using Guix Home, kthxbye.

But to entertain the idea, suppose Alice wants to make her profiles
smaller so that they build faster.  Which sounds more reasonable? 
Bundling groups of packages that fit together into their own manifests,
then instantiating one profile for each, or rolling a six-sided die and
putting the package into whichever bin is number four?  If you're a
machine, you probably think the latter.  What could be more fair than a
six-sided die?  Why, a seven-sided die of course!

> Or worse, if the user doesn't know what search paths are and when
> they can break.
> 
> Also, I still don't see the relation to
> 
> > > I am not debating any legitimacy (<home-profile> is not some
> > > government), I am discussing the reasons, and whether some of the
> > > features (e.g. faster profile building) can be implemented more
> > > generally (not Guix Home-exclusive), without manual
> > > configuration.
> > > [...]
> 
> -- I mention the phrase ‘faster profile building’ here, but I don't
> think I'm implying here that faster build times cause tinier
> profiles, or that tinier profiles don't help or such?  Is there some
> specific phrase in that paragraph you disagree with?  Is there some
> point you consider to be already addressed or not yet addressed or
> some point you consider to not have to be addressed?  I don't know
> what we are disagreeing about here?
We disagree about the question whether users should be granted a method
of declaring multiple profiles to use for their own purposes in
whichever way they see fit through `guix home'.  You are painfully
trying to claim there is no need to do so whereas I not only claim
there is, but also that any existing way of achieving similar results
fails to meet my requirements, which are:

1. multiple profiles can be configured at once
2. profile locations should be specified by the user
3. profile generations are not littered, instead, the user has a way of
linking to /var/guix/profiles/per-user
4. both package lists and manifests are supported
5. existing configurations can be expressed in terms of the new system
6. individual profiles can be "disabled", i.e. not sourced during
activation, but still built
7. individual profiles can lack a manifest, in which case nothing is
built, but they are still sourced on login

With all of the above, home-profile-service would make most of the
currently existing /etc/profile workarounds obsolete.  The exception
would be that /run/setuid-binaries is missing, along with any
underspecified search path.  For the latter we still need a solution
that works regardless of guix home anyway, so it is not a point of
discussion here.

Cheers