[bug#50878] [PATCH] union: Resolve collisions by stable-sort'ing them.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Attila

Am Donnerstag, den 30.09.2021, 08:10 +0000 schrieb Attila Lendvai:
> > > -   (let* ((original-files (list->vector files))
> > > -           (count (vector-length original-files))
> > > -           (stripped-files (vector-map (lambda (_ el)
> > > -                                         (strip-store-file-name
> > > el))
> > > -                                       original-files))
> > > -           (indices (vector-unfold values count)))
> > > 
> > > -   (stable-sort! indices
> > > -                    (lambda (a b)
> > > -                      (string> (vector-ref stripped-files a)
> > > -                               (vector-ref stripped-files b))))
> > > -   (vector-ref original-files (vector-ref indices 0))))
> > 
> > Instead of stable-sort!-ing the indices of a vector, what about
> > stable-sort!-ing (map strip-store-file-name original-files) in more
> > or less one go?
> 
> the hash also needs to be dropped from the path for sorting to be
> useful, but the return value must be the full path, hence the
> complexity with sorting the indices, pointing both to the full paths
> and the cut parts.
This thing has received some replies already to which I already dropped
a comment, so I'll try not to repeat myself here.  If something is
still unclear, go down the sub-thread started by Maxime.

> > I don't think the default collision resolver ought to sort the
> > files.
> > 
> > The rationale behind ignoring certain collisions, e.g. icon caches
> > relies on the fact that Guix will use the correct files because
> > they are put first in the manifest. The hooks themselves have no
> > special names that could put them "always first" and profiles are
> > themselves union-built.
> > 
> > I do however support the addition of sorting methods as collision
> > resolvers in general and would welcome a way of doing so for
> > profiles
> > pre-hook.
> 
> please note that i almost completely lack the knowledge of the
> relevant internals.
> 
> with that in mind, do i read you right? this should add a new
> exported resolver funtion, and leave the default one as it was?
Yes, I think that is safer than actually overriding the default for now
at least.

> and use the new resolver somewhere (where?) that will affect only the
> union of profiles, i.e. user visible effecs when installing software?
> (because DIRECTORY-UNION is called in other contexts also?)
> 
> thanks for the insights! i'd appreciate a bit more higher level
> guidance, and then i'll resend the patch accordingly.
I must admit, I'm at a loss of knowledge myself here.  Perhaps someone
else can jive in and tell you which union-build is done without hooks,
but I fear there might also be none.  For now, simply having the
resolver is in my opinion enough if we don't find the right location as
well.  We can default it later with "first-come-first-serve" exceptions
where needed.

Cheers