> > > I'll modify pepperflashplugin-nonfree now to use the /etc/chromium.d > > > approach only if /etc/chromium.d is available regardless of whether > > > /etc/chromium/default exists. > > > > I guess pepperflashplugin-nonfree could Break versions of chromium prior > > to this directory becoming available -- that would help apt help you > > only work with the cooperating versions, but it might be more trouble > > than it's worth too. > > Creative idea, but I was rather thinking of the opposite, keeping > pepperflashplugin-nonfree compatible with multiple chromium versions. So > still updating /etc/chromium/default as long as an old chromium version is > being used.
given that chromium versions tend to also be security updates, I don't know it's worth losing sleep over keeping older vulnerable versions working... but I'm just a user that's pulling these packages using apt here :) > > Do you intend to use preinst/postinst to back out the changes that were > > made to /etc/chromium/default by the older packages or is that going to > > be too difficult to do? > > It can be done, but it's more work than I can do in short time. Ahh... I see the postrm:purge step of the old package doesn't clean up -- I had assumed it would so it would only be a matter of relocating this code. Yes, I can appreciate it's going to be ugly to strip that code out. (An awk expression could eat everything between the two markers but this is just making the maintainer scripts more and more fragile). I guess at some stage we need to just draw a line under it and acknowledge that all this can't be done in a perfect manner and that the conffile prompt is only going to affect testing upgrades and users of wheezy-backports. Most stable users will just be able to upgrade without it. popcon reports vastly more chromium users than pepperflash-plugin users -- I had wondered if dropping support for older adobe flash would mean there was even more than this: <judd> Popcon data for chromium: inst: 24913, vote: 13831, old: 9414, recent: 1564, nofiles: 104 <judd> Popcon data for pepperflashplugin-nonfree: inst: 4088, vote: 215, old: 3004, recent: 866, nofiles: 3 > Also, it > would only be useful if the new chromium version using /etc/chromium.d > would still also have /etc/chromium/default, so possibly not useful. I > await a new chromium version using /etc/chromium.d in unstable and testing > for this aspect. yes, I can see that you need a package to actually test before you can go much further on this. A chromium supporting this feature could easily land in wheezy/updates (not even wheezy-backports) at the next round of security updates of course. In the mean time, I guess pepperflashplugin-nonfree needs to support both methods for the different chromium versions it might need to work with. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
