Summary: | www-client/chromium: Repackage minor updates as patches | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Florian Philipp <f_philipp> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | kripton, skunk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Florian Philipp
2012-12-16 11:24:36 UTC
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. |