all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* proposal: with-file-writeable
@ 2018-02-10 21:50 Gábor Boskovits
  2018-02-14 13:51 ` Ludovic Courtès
  2018-02-14 23:28 ` Ludovic Courtès
  0 siblings, 2 replies; 11+ messages in thread
From: Gábor Boskovits @ 2018-02-10 21:50 UTC (permalink / raw)
  To: Guix-devel

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

the make-file-writeable function seems a bit too imperative to me, it would
look better if we could have a with-file-writeable function, so that we can
constrain the size effect, and more. Moreover if a file is read-only to
start with, it might be a good idea to keep it that way anyways. WDYT?

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-10 21:50 proposal: with-file-writeable Gábor Boskovits
@ 2018-02-14 13:51 ` Ludovic Courtès
  2018-02-14 19:13   ` Leo Famulari
  2018-02-14 23:28 ` Ludovic Courtès
  1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2018-02-14 13:51 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: Guix-devel

Gábor Boskovits <boskovits@gmail.com> skribis:

> the make-file-writeable function seems a bit too imperative to me, it would
> look better if we could have a with-file-writeable function, so that we can
> constrain the size effect, and more. Moreover if a file is read-only to
> start with, it might be a good idea to keep it that way anyways. WDYT?

Which ‘make-file-writeable’ function?  I don’t see it in master.

Ludo’.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-14 13:51 ` Ludovic Courtès
@ 2018-02-14 19:13   ` Leo Famulari
  2018-02-14 19:38     ` Gábor Boskovits
  0 siblings, 1 reply; 11+ messages in thread
From: Leo Famulari @ 2018-02-14 19:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

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

On Wed, Feb 14, 2018 at 02:51:08PM +0100, Ludovic Courtès wrote:
> Gábor Boskovits <boskovits@gmail.com> skribis:
> 
> > the make-file-writeable function seems a bit too imperative to me, it would
> > look better if we could have a with-file-writeable function, so that we can
> > constrain the size effect, and more. Moreover if a file is read-only to
> > start with, it might be a good idea to keep it that way anyways. WDYT?
> 
> Which ‘make-file-writeable’ function?  I don’t see it in master.

There was a typo; it's ((guix build utils) make-file-writable)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-14 19:13   ` Leo Famulari
@ 2018-02-14 19:38     ` Gábor Boskovits
  0 siblings, 0 replies; 11+ messages in thread
From: Gábor Boskovits @ 2018-02-14 19:38 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Guix-devel

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

2018-02-14 20:13 GMT+01:00 Leo Famulari <leo@famulari.name>:

> On Wed, Feb 14, 2018 at 02:51:08PM +0100, Ludovic Courtès wrote:
> > Gábor Boskovits <boskovits@gmail.com> skribis:
> >
> > > the make-file-writeable function seems a bit too imperative to me, it
> would
> > > look better if we could have a with-file-writeable function, so that
> we can
> > > constrain the size effect, and more. Moreover if a file is read-only to
> > > start with, it might be a good idea to keep it that way anyways. WDYT?
> >
> > Which ‘make-file-writeable’ function?  I don’t see it in master.
>
> There was a typo; it's ((guix build utils) make-file-writable)
>

Sorry, yes, my mistake, it's really  ((guix build utils)
make-file-writable).

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-10 21:50 proposal: with-file-writeable Gábor Boskovits
  2018-02-14 13:51 ` Ludovic Courtès
@ 2018-02-14 23:28 ` Ludovic Courtès
  2018-02-15  7:25   ` Gábor Boskovits
  1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2018-02-14 23:28 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: Guix-devel

Gábor Boskovits <boskovits@gmail.com> skribis:

> the make-file-writeable function seems a bit too imperative to me, it would
> look better if we could have a with-file-writeable function, so that we can
> constrain the size effect, and more. Moreover if a file is read-only to
> start with, it might be a good idea to keep it that way anyways. WDYT?

Now that I found the function in (guix build utils) (thanks for guiding
me!), I see what you mean.  ‘make-file-writable’ is imperative, true,
but I’d say that file system operations are imperative in nature.

A ‘with-file-writeable’ form would give a false sense of “containment” I
think.  Contrary to what the name suggests, its effect would *not* be
limited to the dynamic extent of its body, in the current thread;
instead, the effect would be globally visible on the system.

Last, the style of (guix build utils) is a lesser concern in a way
because its primary use case is package builds.  All this code is
“plumbing” and mostly imperative.

So, all in all, I’d rather keep it this way.

Thoughts?

Ludo’.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-14 23:28 ` Ludovic Courtès
@ 2018-02-15  7:25   ` Gábor Boskovits
  2018-02-15 13:22     ` Ludovic Courtès
  2018-02-15 14:16     ` Marius Bakke
  0 siblings, 2 replies; 11+ messages in thread
From: Gábor Boskovits @ 2018-02-15  7:25 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

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

2018-02-15 0:28 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > the make-file-writeable function seems a bit too imperative to me, it
> would
> > look better if we could have a with-file-writeable function, so that we
> can
> > constrain the size effect, and more. Moreover if a file is read-only to
> > start with, it might be a good idea to keep it that way anyways. WDYT?
>
> Now that I found the function in (guix build utils) (thanks for guiding
> me!), I see what you mean.  ‘make-file-writable’ is imperative, true,
> but I’d say that file system operations are imperative in nature.
>
> A ‘with-file-writeable’ form would give a false sense of “containment” I
> think.  Contrary to what the name suggests, its effect would *not* be
> limited to the dynamic extent of its body, in the current thread;
> instead, the effect would be globally visible on the system.
>
> Last, the style of (guix build utils) is a lesser concern in a way
> because its primary use case is package builds.  All this code is
> “plumbing” and mostly imperative.
>
> So, all in all, I’d rather keep it this way.
>
> Thoughts?
>
>
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?


> Ludo’.
>

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-15  7:25   ` Gábor Boskovits
@ 2018-02-15 13:22     ` Ludovic Courtès
  2018-02-15 13:53       ` Gábor Boskovits
  2018-02-15 14:16     ` Marius Bakke
  1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2018-02-15 13:22 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: Guix-devel

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.

Ludo’.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-15 13:22     ` Ludovic Courtès
@ 2018-02-15 13:53       ` Gábor Boskovits
  0 siblings, 0 replies; 11+ messages in thread
From: Gábor Boskovits @ 2018-02-15 13:53 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-15  7:25   ` Gábor Boskovits
  2018-02-15 13:22     ` Ludovic Courtès
@ 2018-02-15 14:16     ` Marius Bakke
  2018-02-16  6:35       ` Gábor Boskovits
  2018-02-16  8:40       ` Ludovic Courtès
  1 sibling, 2 replies; 11+ messages in thread
From: Marius Bakke @ 2018-02-15 14:16 UTC (permalink / raw)
  To: Gábor Boskovits, Ludovic Courtès; +Cc: Guix-devel

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

Gábor Boskovits <boskovits@gmail.com> writes:

> 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?

In the "strip" phase we already call "make-file-writeable"
unconditionally, so doing it in reset-gzip-permissions as well should be
okay I think.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-15 14:16     ` Marius Bakke
@ 2018-02-16  6:35       ` Gábor Boskovits
  2018-02-16  8:40       ` Ludovic Courtès
  1 sibling, 0 replies; 11+ messages in thread
From: Gábor Boskovits @ 2018-02-16  6:35 UTC (permalink / raw)
  To: Marius Bakke; +Cc: Guix-devel

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

2018-02-15 15:16 GMT+01:00 Marius Bakke <mbakke@fastmail.com>:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
> > 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?
>
> In the "strip" phase we already call "make-file-writeable"
> unconditionally, so doing it in reset-gzip-permissions as well should be
> okay I think.
>

Ok, thanks, I will prepare a patch.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proposal: with-file-writeable
  2018-02-15 14:16     ` Marius Bakke
  2018-02-16  6:35       ` Gábor Boskovits
@ 2018-02-16  8:40       ` Ludovic Courtès
  1 sibling, 0 replies; 11+ messages in thread
From: Ludovic Courtès @ 2018-02-16  8:40 UTC (permalink / raw)
  To: Marius Bakke; +Cc: Guix-devel

Marius Bakke <mbakke@fastmail.com> skribis:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
>> 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?
>
> In the "strip" phase we already call "make-file-writeable"
> unconditionally, so doing it in reset-gzip-permissions as well should be
> okay I think.

Right, especially if this affects a number of packages already.

Ludo’.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2018-02-16  8:40 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-10 21:50 proposal: with-file-writeable Gábor Boskovits
2018-02-14 13:51 ` Ludovic Courtès
2018-02-14 19:13   ` Leo Famulari
2018-02-14 19:38     ` Gábor Boskovits
2018-02-14 23:28 ` Ludovic Courtès
2018-02-15  7:25   ` Gábor Boskovits
2018-02-15 13:22     ` Ludovic Courtès
2018-02-15 13:53       ` Gábor Boskovits
2018-02-15 14:16     ` Marius Bakke
2018-02-16  6:35       ` Gábor Boskovits
2018-02-16  8:40       ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.