Gs

Gs

[Andreas Enge]

Hello,

the following commit
commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Mon May 9 15:54:34 2016 +0200

    gnu: ghostscript: Do not build the statically-linked 'gs' binary.
    
    * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
    'build-so' and 'install-so' phases.  Replace 'build' and 'install'
    phases.

removes "gs" from the ghostscript package. However, this is the usual program
that people expect. For instance, unison uses it for building its
documentation. Is there a dynamically linked binary which replaces gs?
If yes, should we add a symbolic link?

If not, I would suggest to revert this commit.

Ceterum censeo that we should not optimise for size by sacrificing
functionality and ease of handling (cf. separate outputs).

Andreas

Re: Gs

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès <ludo@gnu.org>
> Date:   Mon May 9 15:54:34 2016 +0200
>
>     gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>     
>     * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
>     'build-so' and 'install-so' phases.  Replace 'build' and 'install'
>     phases.
>
> removes "gs" from the ghostscript package. However, this is the usual program
> that people expect. For instance, unison uses it for building its
> documentation. Is there a dynamically linked binary which replaces gs?
> If yes, should we add a symbolic link?

This also broke our “lilypond” package on core-updates.

~~ Ricardo

Re: Gs

[Ludovic Courtès]

Hi!

Andreas Enge <andreas@enge.fr> skribis:

> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès <ludo@gnu.org>
> Date:   Mon May 9 15:54:34 2016 +0200
>
>     gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>     
>     * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
>     'build-so' and 'install-so' phases.  Replace 'build' and 'install'
>     phases.

Ahem, I plaid guilty.

> removes "gs" from the ghostscript package. However, this is the usual program
> that people expect. For instance, unison uses it for building its
> documentation. Is there a dynamically linked binary which replaces gs?
> If yes, should we add a symbolic link?

I think so.

For the current solution (avoiding a full rebuild), see commit
61dc82d9b90d0545739c30bfc33003bd062071f0.  LilyPond could hard-code the
file name of ‘gsc’.

Alternately, we could provide a wrapper containing a ‘gs’ symlink.

This has been discussed with Efraim IIRC, though I can’t find the thread
now.

Thoughts?

Ludo’.

Re: Gs

[Andreas Enge]

Hello!

On Sat, Jul 23, 2016 at 01:03:07PM +0200, Ludovic Courtès wrote:
> For the current solution (avoiding a full rebuild), see commit
> 61dc82d9b90d0545739c30bfc33003bd062071f0.  LilyPond could hard-code the
> file name of ‘gsc’.

This looks like too much work to implement for each package separately.
And as a permanent solution, I do not like it.

> Alternately, we could provide a wrapper containing a ‘gs’ symlink.

This would be one option. Or we could add another package, corresponding
to the previous definition, that we would use only as an input to the
packages in core-updates that do not build right now. This solution could
be implemented using copy-paste and not take much time. I would then also
remove the ad-hoc lilypond patching.

Then after core-updates is merged, we could add the gs->gsc link to our
ghostscript packages.

What do you think?

Andreas

Re: Gs

[Ludovic Courtès]

¡Hola!

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, Jul 23, 2016 at 01:03:07PM +0200, Ludovic Courtès wrote:
>> For the current solution (avoiding a full rebuild), see commit
>> 61dc82d9b90d0545739c30bfc33003bd062071f0.  LilyPond could hard-code the
>> file name of ‘gsc’.
>
> This looks like too much work to implement for each package separately.
> And as a permanent solution, I do not like it.
>
>> Alternately, we could provide a wrapper containing a ‘gs’ symlink.
>
> This would be one option. Or we could add another package, corresponding
> to the previous definition, that we would use only as an input to the
> packages in core-updates that do not build right now. This solution could
> be implemented using copy-paste and not take much time. I would then also
> remove the ad-hoc lilypond patching.

I went ahead and pushed these two commits, which seem to address the
issue:

  d8eb912 * gnu: Use 'ghostscript-gs' in packages that need the 'gs' command.
  71eba3e * gnu: Add 'ghostscript-gs' and 'ghostscript-gs-with-x'.

> Then after core-updates is merged, we could add the gs->gsc link to our
> ghostscript packages.

Yes, we should do that afterwards.

Apologies for the breakage!

Ludo'.

Re: Gs

[Efraim Flashner]

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

On Sat, Jul 23, 2016 at 01:03:07PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Andreas Enge <andreas@enge.fr> skribis:
> 
> > the following commit
> > commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> > Author: Ludovic Courtès <ludo@gnu.org>
> > Date:   Mon May 9 15:54:34 2016 +0200
> >
> >     gnu: ghostscript: Do not build the statically-linked 'gs' binary.
> >     
> >     * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
> >     'build-so' and 'install-so' phases.  Replace 'build' and 'install'
> >     phases.
> 
> Ahem, I plaid guilty.
> 
> > removes "gs" from the ghostscript package. However, this is the usual program
> > that people expect. For instance, unison uses it for building its
> > documentation. Is there a dynamically linked binary which replaces gs?
> > If yes, should we add a symbolic link?
> 
> I think so.
> 
> For the current solution (avoiding a full rebuild), see commit
> 61dc82d9b90d0545739c30bfc33003bd062071f0.  LilyPond could hard-code the
> file name of ‘gsc’.
> 
> Alternately, we could provide a wrapper containing a ‘gs’ symlink.

I think this was the option I liked the most, I don't believe any
functionality is lost with a gs->gsc symlink, and it would still keep
the reduced size of the closure.

> 
> This has been discussed with Efraim IIRC, though I can’t find the thread
> now.

I think we mostly discussed it on IRC

> 
> Thoughts?
> 
> Ludo’.
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Gs

[Federico Beffa]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> the following commit
> commit eb354bdacbf4154ec66038dac07f19bf4ced1fad
> Author: Ludovic Courtès <ludo@gnu.org>
> Date:   Mon May 9 15:54:34 2016 +0200
>
>     gnu: ghostscript: Do not build the statically-linked 'gs' binary.
>
>     * gnu/packages/ghostscript.scm (ghostscript)[arguments]: Remove
>     'build-so' and 'install-so' phases.  Replace 'build' and 'install'
>     phases.
>
> removes "gs" from the ghostscript package. However, this is the usual program
> that people expect. For instance, unison uses it for building its
> documentation. Is there a dynamically linked binary which replaces gs?
> If yes, should we add a symbolic link?
>
> If not, I would suggest to revert this commit.
>
> Ceterum censeo that we should not optimise for size by sacrificing
> functionality and ease of handling (cf. separate outputs).

+1

This broke 'chez-scheme' as well on core-updates.

Fede