Opened 4 years ago

Closed 4 years ago

Last modified 19 months ago

#24586 closed defect (fixed)

packages whose type is "script" must have executable spkg-install

Reported by: tmonteil Owned by:
Priority: major Milestone: sage-8.2
Component: packages: optional Keywords:
Cc: embray Merged in:
Authors: Thierry Monteil Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: 81352f5 (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description

It is all in the title. Fixed for r_jupyter in #24585, pyopenssl is OK, texlive remains:

sage -i texlive

[...]

cd '/opt/sagemath/sage-source' && \
    source '/opt/sagemath/sage-source/src/bin/sage-env' && \
    sage-logger -p '/opt/sagemath/sage-source/build/pkgs/texlive/spkg-install' /opt/sagemath/sage-source/logs/pkgs/texlive.log
[texlive] /opt/sagemath/sage-source/build/bin/sage-logger: line 89: /opt/sagemath/sage-source/build/pkgs/texlive/spkg-install: Permission denied
Makefile:2984: recipe for target 'texlive' failed

Change History (9)

comment:1 Changed 4 years ago by tmonteil

  • Branch set to u/tmonteil/packges_whose_type_is__script__must_have_executable_spkg_install

comment:2 Changed 4 years ago by tmonteil

  • Cc embray added
  • Commit set to 81352f59f223c1dd48e6c85e4b413baaed4a972e
  • Status changed from new to needs_review
  • Summary changed from packges whose type is "script" must have executable spkg-install to packages whose type is "script" must have executable spkg-install

New commits:

81352f5#24586 : make build/pkgs/texlive/spkg-install executable

comment:3 Changed 4 years ago by tmonteil

Apparently, texlive script is broken anyway, see also #21922.

comment:4 follow-up: Changed 4 years ago by embray

  • Status changed from needs_review to needs_work

I'm thinking we should just get rid of "script" type. It only applies to three packages and there's no good reason for it. It's a misuse of "package type" anyways, which we'd like to get away from being a reflection of how a package is installed and more a reflection of under what circumstances the package should be installed (i.e. standard vs. optional).

I would propose that we convert these packages' types to "optional", treat "script" as an alias for "optional", and write a deprecation warning in the off chance that someone tries to use "script" type again.

comment:5 Changed 4 years ago by embray

Additionally if wanted to add some explicit marker that there is no "source tarball" for the package that would be fine too.

comment:6 Changed 4 years ago by jdemeyer

  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_work to positive_review

At least this fixes something, why not merge it?

comment:7 Changed 4 years ago by embray

I guess. I can open an issue for my further suggestions.

comment:8 Changed 4 years ago by vbraun

  • Branch changed from u/tmonteil/packges_whose_type_is__script__must_have_executable_spkg_install to 81352f59f223c1dd48e6c85e4b413baaed4a972e
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:9 in reply to: ↑ 4 Changed 19 months ago by mkoeppe

  • Commit 81352f59f223c1dd48e6c85e4b413baaed4a972e deleted

Replying to embray:

I'm thinking we should just get rid of "script" type. It only applies to three packages and there's no good reason for it. It's a misuse of "package type" anyways, which we'd like to get away from being a reflection of how a package is installed and more a reflection of under what circumstances the package should be installed (i.e. standard vs. optional).

I would propose that we convert these packages' types to "optional", treat "script" as an alias for "optional", and write a deprecation warning in the off chance that someone tries to use "script" type again.

#29287 makes roughly these proposed changes (but without the soft transition using deprecation).

Note: See TracTickets for help on using tickets.