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.
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. 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. 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.
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.
Oh, and then provide incremental diffs whenever you update the package rather than exchanging the diff.
In the absence of a source service to do this (which I suspect would be quite hard to write), I think it will create a lot more work for the packager :-/
Not sure - I have a script to update the GCC package to a SVN revision and I never used source services. A source service to provide a diff between a previous revision and head (or between two revisions) shouldn't be terribly hard to write though (no, I'm not volunteering ;)). Richard. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org