8000 A simple debugger to check and verify files and correct operation of … by KooshaYeganeh · Pull Request #7792 · Slicer/Slicer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

A simple debugger to check and verify files and correct operation of … #7792

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

KooshaYeganeh
Copy link

…the software in Linux

@KooshaYeganeh
Copy link
Author

A simple debugger to check and verify files and correct operation of the software in Linux

@pieper
Copy link
Member
pieper commented Jun 7, 2024

Hi and thanks for the contribution 👍

I like the idea of verifying an installation, but I feel this approach will be brittle, since things like the number of files and certainly the hashes will change fairly often and will need to be manually updated. If you want to use this approach, probably we need a way to automatically calculate the check values from a known-good installation.

On the other hand, it could be better to define a correct installation functionally, meaning we would check if the software is able to run and perform certain operations correctly. This approach could have the added advantage of working across platforms and might catch errors that the current script wouldn't catch.

Maybe you can describe in more detail why you think this script is needed. In my experience if the tar.gz file is correctly downloaded and extracted everything should be okay. Maybe we need a better way to check the hash of the downloaded archive?

@KooshaYeganeh
Copy link
Author

Thank you for your detailed review
The reason for the development of this script was precisely the fact that in many cases people download the tar file from unknown sources and it is not clear whether this file is exactly the same as the original source file or whether changes have been made to it or not. This issue is especially acute when A person who is an amateur in the subject of software.
Regarding the installation process, I have a script that makes it easy to install the file on the Hamel Open Sousse system. I tried to automate the steps of downloading and installing Slicer.
suse --install slicer

@pieper
Copy link
Member
pieper commented Jun 9, 2024

Did you see we provide checksums for the downloads? I think it would be easier and more scalable to provide scripts that download the archives and then confirm these checksums.

https://download.slicer.org/#checksums

@lassoan
Copy link
Contributor
lassoan commented Jun 10, 2024

Note that you don't need to scrape the dowoad site but you can get the information using a web API. For example, you can find release information here:

https://download.slicer.org/find?os=win&stability=release

It was just an example, there should be some other API to get checksum of a specific release version.

@lassoan
Copy link
Contributor
lassoan commented Jun 10, 2024

in many cases people download the tar file from unknown sources

As far as I know, download.slicee.org site is not blocked anywhere in the world. Why do you think people would download the file from unknown sources instead?

@RafaelPalomar has been working on making Slicer available in Linux app stores. Maybe you could join his efforts with him.

By the way Windows and macOS (that is used by almost all "amateur" users) has per-file integrity check already (in the Windows installer and in macOS signed binaries). If Slicer is added to a linux app store then all files would be fingerprinted on Linux, too.

Fingerprint check at every startup could be useful for regulatory approvals, but tour script does not do an exact check.

It could be useful to have an automatic troubleshooter for diagnosing and fixing startup issues, but your script does very little of that.

Having an application error reporter (collect system information, logs, stack trace of a crash, etc. and make it easy to send it) would be useful, too but your script does not really do this.

Checking system health (free disk space, temporary folder writable, etc.) could be nice, but we do some of this already and ir should be part of the application startup process and work on all operating systems.

So, we need to step.back step and figure out what problem you want to solve and improve on the existing solutions for that. You can jo8n our next developer meeting on Tuesday to discuss this in person - https://discourse.slicer.org/c/community/hangout/20

@RafaelPalomar
Copy link
Contributor

@RafaelPalomar has been working on making Slicer available in Linux app stores. Maybe you could join his efforts with him.

Yes, I have been working on a flatpak version of Slicer:

  • Initially one that would build the entire stack and packages it in a flatpak. This wasn't completely compatible with Slicer extensions and it wasn't easy to maintain.
  • The second option is to wrap the official slicer binaries in a flatpak. This is feasible, but for this to happen Slicer needs to enable startup options to control where extensions and python files could be installed. Flatpak space is read-only, but these files could be installed in local user directories.

Did you see we provide checksums for the downloads? I think it would be easier and more scalable to provide scripts that download the archives and then confirm these checksums.

  • Flatpak builder would checksum the slicer binary package before distribution, solving this issue.

I would like to re-take on this effort when I have a little bit more time. All help welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0