From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: proposal: with-file-writeable Date: Thu, 15 Feb 2018 14:53:52 +0100 Message-ID: References: <87wozfp2wk.fsf@gnu.org> <87bmgqbd5s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114403d0e8cde80565408ef1" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emJz3-0003SQ-9K for guix-devel@gnu.org; Thu, 15 Feb 2018 08:53:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emJz2-0002bS-6L for guix-devel@gnu.org; Thu, 15 Feb 2018 08:53:57 -0500 In-Reply-To: <87bmgqbd5s.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel --001a114403d0e8cde80565408ef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-02-15 14:22 GMT+01:00 Ludovic Court=C3=A8s : > G=C3=A1bor Boskovits 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 afte= r > > 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 stor= e > > anyway. I feel that reseting the permissions is unneccesary additional > > complexity. WDYT? > > I don=E2=80=99t know, is this (read-only permission on installed files) a= common > problem? > > As you can see I=E2=80=99m 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=E2=80=99d have to repeat ourselves in pac= kage > 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=E2=80=99. > --001a114403d0e8cde80565408ef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -02-15 14:22 GMT+01:00 Ludovic Court=C3=A8s <ludo@gnu.org>:
=
G=C3=A1bor 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 aft= er
> 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 p= hase
> at the beginning, as we finally end up with a read-only one in the sto= re
> anyway. I feel that reseting the permissions is unneccesary additional=
> complexity. WDYT?

I don=E2=80=99t know, is this (read-only permission on installed fil= es) a common
problem?

As you can see I=E2=80=99m fairly conservative when it comes to changing (g= uix
build utils).=C2=A0 :-)

The reason for this is that changing it entails full rebuilds.=C2=A0 Thus,<= br> 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.=C2=A0 At the same time, we try to<= br> make changes there only when we=E2=80=99d have to repeat ourselves in packa= ge
recipes.=C2=A0 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 package= s 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 wh= en we
can use pypi. I don't know how common it is in other ar= eas.
=C2=A0
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 the= m with one commit. It should be based on core-updates, of course,
and not in this round, I guess.

Ludo=E2=80=99.

--001a114403d0e8cde80565408ef1--