Skip to content
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

Delta support #43

Open
barthalion opened this issue Jan 2, 2017 · 6 comments
Open

Delta support #43

barthalion opened this issue Jan 2, 2017 · 6 comments
Assignees
Milestone

Comments

@barthalion
Copy link

barthalion commented Jan 2, 2017

It would be great if repose could also generate or at least add delta files to the database.

@vodik
Copy link
Owner

vodik commented Jan 3, 2017

Yeah, should probably get around to getting that. I'll see what I can do...

@vodik
Copy link
Owner

vodik commented Jan 3, 2017

Started hacking around with this on the delta-support branch.

vodik added a commit that referenced this issue Jan 6, 2017
Preserve delta information when reading and writing the database.
Initial support for #43
@vodik
Copy link
Owner

vodik commented Jan 6, 2017

Okay, so as a start, its fairly straightforward to add support to serialise delta information. This, at the very least, means that I don't lose that information.

But I never really stopped to think about how to support deltas in this tool. I guess I need to, when calculating which files trigger an update, generate a delta between the old version an the new version, and record that information.

Few open questions/musing out loud):

  1. Should I automatically remove old deltas? Only one? More? Calculate when the deltas exceed the package's size? I don't actually know how well pacman supports deltas tbh.
  2. Should I sign deltas I produce?
  3. Where to the deltas go, when the package pool and the repository root don't match. Should they be symlinked?
  4. Are there cases where I shouldn't generate deltas? Like in the case when I detect I need to rebuild the database because package checksum/timestamp mismatch (but no version bump), I guess making a delta between those releases don't make sense, and all existing deltas have to be invalidated.

And random footnote, looks like pacman expects deltas to have a md5 checksum. I wonder if there's support for anything else... or if that should also get added upstream.

vodik added a commit that referenced this issue Jan 6, 2017
Preserve delta information when reading and writing the database.
Initial support for #43
@vodik
Copy link
Owner

vodik commented Jan 6, 2017

Well, delta serialisation support is on master, there's still a long road ahead though...

@vodik vodik added this to the 8 milestone Jan 6, 2017
@vodik vodik self-assigned this Jan 6, 2017
vodik added a commit that referenced this issue Jan 6, 2017
Preserve delta information when reading and writing the database.
Initial support for #43
vodik added a commit that referenced this issue Jan 6, 2017
Preserve delta information when reading and writing the database.
Initial support for #43
@barthalion
Copy link
Author

Should I automatically remove old deltas? Only one? More? Calculate when the deltas exceed the package's size? I don't actually know how well pacman supports deltas tbh.

I don't know either to be honest. Depends if it can chain applying deltas from locally cached version that is no longer available in the repository to the latest version. If it can, I guess no delta should be removed automatically.

Should I sign deltas I produce?

No idea if it supports signed deltas…

Where to the deltas go, when the package pool and the repository root don't match. Should they be symlinked?

I didn't notice that the package pool can be in different directory now. I guess it should be in the pool?

On a side note, I didn't expect you to implement it overnight; it's just something that would be nice to have. From what I see know, delta support in pacman is terribly slow for the biggest packages (and for small ones it makes no sense to use it). I guess it differs from the yum/dnf implementation where it works quite okay.

@vodik
Copy link
Owner

vodik commented Jan 7, 2017

Yeah, its not coming overnight, that's for sure. I'll need to play with it.

From what I see know, delta support in pacman is terribly slow for the biggest packages

I've avoided it actually because my understanding is its basically not really supported. I don't think anyone wants to use deltas on the official repos and thus noone is really auditing or testing that code.

I mean, with all the discussion about abandoning md5sum by default (which repose doesn't offer anyways), deltas are still using a md5 checksum. Granted, I think the resulting file from the applied delta is still compared to the appropriate signatures, so its not that bad.

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

No branches or pull requests

2 participants