2018-02-15 14:22 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:
Gábor Boskovits <boskovits@gmail.com> skribis:

> Ok, the keep it this way. Another question, this came up, as
> I was trying to find a nice solution to reset-gzip-timestamps failing.
> I got different pieces of advice if I should reset the permissions after
> resetting the timestamp, but I'm still not sure. It seems that the easiest
> way to this would be to just add a call to make-file-writable to the phase
> at the beginning, as we finally end up with a read-only one in the store
> anyway. I feel that reseting the permissions is unneccesary additional
> complexity. WDYT?

I don’t know, is this (read-only permission on installed files) a common
problem?

As you can see I’m fairly conservative when it comes to changing (guix
build utils).  :-)

The reason for this is that changing it entails full rebuilds.  Thus,
the approach so far is to try to make the procedures in there fairly
generic (with keyword/optional parameters, etc.) so that they are
applicable to a wide range of use cases.  At the same time, we try to
make changes there only when we’d have to repeat ourselves in package
recipes.  If a problem shows up in just one package, we adjust the
package definition and leave (guix build utils) unchanged.


I've seen this mostly with packages coming from git checkout in the python world.
I've seen at least two packages in the last three month. It is mostly test data.
It actually seems to be common there, but usually it is not a problem when we
can use pypi. I don't know how common it is in other areas.
 
I also don't know if we have any other phase where these kind of permission
problems can lead to errors, but it would be nice, if we could check that, and
fix all of them with one commit. It should be based on core-updates, of course,
and not in this round, I guess.

Ludo’.