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
