Currently, each update for chromium results in a new 200 MiB download, even if it is just an update from 23.0.1271.95 to 23.0.1271.97, for example. Given that chromium updates quite often, this is a real problem for users with slow or volume-limited connections. Usually, the real change is just a few lines of code. Couldn't these changes just be distributed as patches derived from the first stabilized version of the same major release? I consider this somewhat security relevant as currently I and probably other users as well have to delay updates until we have access to a suitable internet connection (maybe once every two weeks in my case). Reproducible: Always Steps to Reproduce: 1. tar xf /usr/src/portage/distfiles/chromium-23.0.1271.64.tar.bz2 2. tar xf /usr/src/portage/distfiles/chromium-23.0.1271.95.tar.bz2 3. diff -Naur chromium-23.0.1271.64 chromium-23.0.1271.95 > chromium-23.0.1271.95.patch 4. du -h chromium-23.0.1271.95.patch Actual Results: 216K chromium-23.0.1271.95.patch
Nobody forces you to update to the new version. If broadband speed/size is an issue for you, you can mask the versions that are greater to the one you have installed. I suspect, that patching a stable release will be too much effort compared to a simple ebuild bump
I have thought about doing this in the past; it will obviously work best for stable channel releases with the same major version. I can easily write a script to generate the diff and upload it to my devspace. I'll give it a shot on the next stable channel bump if nobody objects.
(In reply to comment #1) > Nobody forces you to update to the new version. If broadband speed/size is > an issue for you, you can mask the versions that are greater to the one you > have installed. So you are telling me I should ignore potentially security relevant updates; for a web browser of all things? Now if there was a regular GLSA for chromium ... Seriously, telling me to stop using chromium would have been a better advice. > I suspect, that patching a stable release will be too much > effort compared to a simple ebuild bump I don't see what's complicated about the three steps I've outlined. Easily scriptable, too. But if you tell me that's not feasible for some reason I guess I'll have to accept that.
(In reply to comment #3) > (In reply to comment #1) > > I suspect, that patching a stable release will be too much > > effort compared to a simple ebuild bump > > I don't see what's complicated about the three steps I've outlined. Easily > scriptable, too. But if you tell me that's not feasible for some reason I > guess I'll have to accept that. Seems Mike and I wrote our comments simultaneously, so just ignore that part.
(In reply to comment #2) > I have thought about doing this in the past; it will obviously work best for > stable channel releases with the same major version. > > I can easily write a script to generate the diff and upload it to my > devspace. I'll give it a shot on the next stable channel bump if nobody > objects. Sounds good to me. Watch out for binary files though. I'm not sure what diff will do in that case (my guess is just say "binary files a and b differ" but no real diff). I'm also working on making the tarballs smaller by removing unnecessary things from them and using a better compression alogrithm (xz instead of bz2). Another option would be binary diffs between the tarballs (that could even be a Gentoo-wide thing, we could auto-generate these things on the mirrors).
(In reply to comment #5) > Sounds good to me. Watch out for binary files though. I'm not sure what diff > will do in that case (my guess is just say "binary files a and b differ" but > no real diff). That's a good point. How do you feel about using a binary diff tool like dev-util/xdelta?
(In reply to comment #6) > How do you feel about using a binary diff tool like > dev-util/xdelta? Totally fine.
(In reply to comment #3) > (In reply to comment #1) > > Nobody forces you to update to the new version. If broadband speed/size is > > an issue for you, you can mask the versions that are greater to the one you > > have installed. > > So you are telling me I should ignore potentially security relevant updates; > for a web browser of all things? Now if there was a regular GLSA for > chromium ... > > Seriously, telling me to stop using chromium would have been a better advice. Seriously, I don't like helping people with this attitude.
(In reply to comment #8) > (In reply to comment #3) > > (In reply to comment #1) > > > Nobody forces you to update to the new version. If broadband speed/size is > > > an issue for you, you can mask the versions that are greater to the one you > > > have installed. > > > > So you are telling me I should ignore potentially security relevant updates; > > for a web browser of all things? Now if there was a regular GLSA for > > chromium ... > > > > Seriously, telling me to stop using chromium would have been a better advice. > > Seriously, I don't like helping people with this attitude. I apologize. It wasn't meant as a personal attack. The last remark was also not meant to be sarcastic, even if it sounds that way. I actually consider that a better wontfix argument (if it has to be) than delaying security updates.
This bug has been sitting for over a decade; I'm not inclined to distribute binary patches and the new binhost will provide a mechanism of fetching binaries if a full compilation is undesirable.
