Re: proposal: with-file-writeable

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2643 bytes --]