search

ScoopInstaller / Scoop

A command-line installer for Windows.
https://scoop.sh
Other
21.26k stars 1.41k forks source link

Clean command is not a solution #3789

Closed quantuumsnot closed 2 years ago

quantuumsnot commented 4 years ago

Better remove that clean and add deltas for updates ... After seeing the sizes of some updates like kicad's 1.1GB latest update while we still have the last update of 1.1GB it will be better to diff patch the apps instead of wasting storage space, time waiting to actually extract the archives and especially traffic (you'll kill all megabytes in your mobile data plan)

Calinou commented 4 years ago

Are delta updates feasible without requiring application developers to generate and host specific files? If not, there's no real point in doing this as convincing application developers to do extra work for Scoop is a difficult task.

quantuumsnot commented 4 years ago

That extra work is ~10 lines in PowerShell using fc or diffutils ... or directly using git

Deide commented 4 years ago

Calinou is referring to application developers, not scoop developers. The question is whether delta updates are feasible without requiring application developers to generate and host the patches for each version.

In other words, is it feasible for Scoop (or bucket maintainers) to host patch files for updates? How many patches will be hosted? Say there are 10 versions between your currently installed application and the latest application - is a patch hosted (and delivered) for each version? It would also require maintainers to download each new update to create and then host the patch - where as now, if hashes are provided, downloads can be avoided entirely.

If that is indeed feasible, then the process (for bucket maintainers) would probably be something along the lines of:

  1. Download new update
  2. Temporarily extract/install without linking persistent items
  3. Compress application into some archive
  4. Create a patch by diffing against the previous version's archive
  5. Delete previous version's archive and store current archive for future patches.
  6. Add patch to some hosted directory of patches that people will download and apply for updates - probably sequentially.

For end users, it would probably require them to do a similar process of removing persistence links, compressing, applying the patch(es), then expanding and relinking persistence. Would this be a fair way to summarise the process?

quantuumsnot commented 4 years ago

I think it is because the storage space used on their machines will be lowered too, and generally patching+copying is faster than downloading, extracting and copying the whole file(s). Also there's no need to patch between two archives but the files can be copied and patched into the dir for the latest app version

Deide commented 4 years ago

Not sure I follow. I think you need to clearly outline the process from the bucket maintainer's view, and from the user installation/update view.

quantuumsnot commented 4 years ago

Fine.

What is faster and using less resources when speaking of application updates? A) Downloading the whole archive of the new version and manually cleaning (still buggy) the old versions B) Downloading only the changed parts of the new version without deleting old versions AND holding the changes as patch updates/update history?

Deide commented 4 years ago

A lot of miscommunication here. I wasn't asking for justification, I was asking for implementation since the process I outlined was either unnecessary or inadequate, which was confusing me.

The issue is called "Clean command is not a solution", but surely you'd still have to clean up old versions as an end-user with something like clean with what little you've specified. I had assumed you wanted to bypass the need for that by patching in place (which would also require the patching to be isomorphic)

It feels like you've misread every comment in this issue, so now I'll just end my participation with my opinion: I don't think it's a good fit for Scoop, but it's an interesting idea for sure.

quantuumsnot commented 4 years ago

Implementations could be found everywhere. For example PS-BinDiff

r15ch13 commented 4 years ago

xdelta works quite good. Tested it with kicad-5.1.5_2-x86_64.exe to kicad-5.1.5_3-x86_64.exe. It creates a ~21 MB patch file. But where should theses patches be hosted?

Deide commented 4 years ago

Not diffing algorithms/programs, but feature implementations, haha.

I also tried xdelta yesterday and thought it would work out well too. One potential problem - if we're talking about in-place patching - is that the patches are not reversible with xdelta, so two patches would need to be generated to enable version downgrades/rollbacks.

quantuumsnot commented 4 years ago

Diff patching to older version is the same - if we have base version 1.0, dir with patches from 1.1 to 1.5, our current version is 1.5 and we want to return to 1.4, there are two variants:

  1. We already have the files for version 1.4 because we patched for all versions from 1.0 to 1.5 *
  2. Just diffpatch again from 1.0 to 1.4 or 1.3->1.4, etc and then only change the current version to the older 1.4

But where should theses patches be hosted?

Where the main archives are hosted, for example github.com/KiCad/kicad-winbuilder/releases/patches/

quantuumsnot commented 2 years ago

Thanks to @rashil2000 this was closed without any explanation ...

Any movement on the idea? My scoop dir is around ~1368GB, ~80% of them taken by older app versions :D

rashil2000 commented 2 years ago

This is out of scope for Scoop

quantuumsnot commented 2 years ago

Care to explain why?

rashil2000 commented 2 years ago
quantuumsnot commented 2 years ago
  • Releasing/creating/storing update deltas is not the responsibility of Scoop - package developers need to do that

So, you're telling us that Scoop has a contract as a (kinda) human that has written rules what can do and what cannot? Seems legit

  • Scoop is just not designed to work this way - it will require fundamental and significant changes to manifest schemas and package management architecture to implement this, not to mention each random package out there will have different delta application procedures.

This sounds exactly how our local politicians try to "close" our eyes during elections or when they report what they have done

Bye!

rashil2000 commented 2 years ago

This sounds exactly how our local politicians try to "close" our eyes during elections or when they report what they have done

Yep, except you pay your politicians for doing so 😉

quantuumsnot commented 2 years ago

Why are you so sure we are not paying people to use scoop and similar programs to do their jobs?

rashil2000 commented 2 years ago

You are paying people to use Scoop?

quantuumsnot commented 2 years ago

Yes