On Wed, 11 Sep 2013, Adam Spiers wrote:
Richard Biener (rguenther@suse.de) wrote:
On Wed, 11 Sep 2013, Adam Spiers wrote:
Richard Biener (rguenther@suse.de) wrote:
Or completely alternative to this whole scheme just package a diff alongside a released tarball.
Nice thinking outside the box :-)
Bonus: you get the possibility of being able to verify its contents with an available signature.
I don't understand this point. You mean verify the contents of the released tarball? But if the diff is not also verified then isn't that rather pointless? Also, a git hash is equivalent to an integrity check (albeit an unsigned one).
Yes, verify the contents of the released tarball. SCMs other than git don't have that hash as integrity check.
IIRC mercurial and monotone do, at least. And probably bzr too.
Bonus 2: less load on the source server(?)
tar_scm caches, so I'm not sure that argument's too compelling.
I mean the source server stores each and every file that ever was in any source package.
Sounds like you're more familiar with the OBS server-side implementation than me. Are you saying that for every single tarball uploaded, OBS keeps an unpacked version server-side? That surprises me, because I know that it keeps the *packed* version, and keeping both seems very wasteful (except if the unpacked version was part of a cache).
I think it only keeps the (compressed) tarball.
So if you update the tarball many times the source server ends up storing each tarball forever. Just adding (or updating) a patch should be cheaper.
I think that would probably depend on the size of the tarballs, the size of the patches, and the frequency of updates. Uncompressed patches can be quite wasteful too.
Oh, of course. For example the gcc 4.8.0 -> 4.8.1 diff is 1.7MB compressed while the tarball is 84MB compressed. And I believe rpm handles compressed patches (or the source service has compressed storage maybe) Changes on non-release branches are much larger though.
It may be that with source services the tarballs are not stored permanently(?) but only cached (and the cache is garbage collected). Of course that would have issues with digging up old revisions of packages if the source used in the source service vanishes.
Don't forget that source services can be client-side-only, via disabledrun mode.
Bonus 3: easier to see what the changes since a release are.
Easier for who? Only for packagers, and excluding the one who packaged the diff (since they already had to have a clone of the repo in order to make the diff in the first place). So again, not hugely compelling IMHO.
Well, for GCC for example you at the moment get changes like
Mon Sep 9 11:56:02 UTC 2013 - rguenther@suse.com
- Update to gcc-4_8-branch head (r202388). - Backports regression fixes for all architectures. * includes changes in aarch64-pthread-option.patch
and simply the source tarball exchanged. If I'd have packed a diff from the last update (r201525) you can easily browse that for malicious changes (given the source tarball would be digitally signed and verified).
Of course one reason that I wouldn't accept outside submitrequests that update the source tarball ;) Don't trust anybody but myself.
Well, that's another good reason to avoid using an SCM which doesn't have integrity built into the design :-)
Heh - if only changing the SCM of a project was easy ... Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org