Hi! fedora-release-11 is out now and I plan to push rpmfusion-{non,}free-release-11 as well. The mirrormanager redirect is in place (thx adrian!) so it should just work and people that run rawhide now will stay on F11. But rpmfusion for F11 uses different keys for signing than in F9 or F10. The public keys for those signing keys are part of the rpmfusion-{non,}free-release-10.9x/-11 package. But those will get signed with the new key as well. And there is a big risk that the new repo files (that point to the public keys) will get created as rpmnew files on the systems of our users. IOW: A lot of users (maybe all; not sure, maybe preupgrade does the right thing) that update from earlier Fedora versions would have to do something manual to get RPM Fusion running properly again after the update. That is not ideal, hence I consider to do these things: - mark the repo files for the initial rpmfusion-{non,}free-release-11 package as %config instead of %config(noreplace). That way we make sure the new repo files get into the right place and actually used by yum; if the old repo files had been modified then they get saved as .rpmsave files and users would need to merge those changes into the new files (but they would have to do that anyway, even if the files would be marked as %config(noreplace)) - get the f11 public key into the rpmfusion-free-release packages for F9 and F10; that way users that update frequently will have the new key installed already and everything should just work Does that sound like a plan? Yes, I'm well aware that it has some downsides, but afaics it's the one that works painlessly for most people. Or am I missing a better way?

On Di Mai 12 2009, Thorsten Leemhuis wrote: > - mark the repo files for the initial rpmfusion-{non,}free-release-11 > package as %config instead of %config(noreplace). That way we make sure > the new repo files get into the right place and actually used by yum; if > the old repo files had been modified then they get saved as .rpmsave > files and users would need to merge those changes into the new files > (but they would have to do that anyway, even if the files would be > marked as %config(noreplace)) > Does that sound like a plan? Yes, I'm well aware that it has some > downsides, but afaics it's the one that works painlessly for most > people. Or am I missing a better way? Imho repo config files must not be marked as %config without noreplace, because they may contain vital options that may mess up the whole system if they are overwritten, e.g. if options like excludepkgs, priority or protect are removed.

In the fedora.repo file from F10, there is $basearch used in the URL of the gpgkey, maybe it is also possible to use $releasever there, so that it is possible to use the same gpgkey URL for several Fedora Releases, e.g. gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-$releasever

On Do Mai 14 2009, Thorsten Leemhuis wrote: > Our repo files OTOH contain vital options that are needed to make things > work. And people that do such major changes to the repo files really > should expect that they need to revisit those when doing a update to a > new major release. People who do not change their repo file will also not get any .rpmnew file.

If you expect people that changed their repo config

to check them after a new major release, what is then wrong with not overwriting theirs?

> And yes, I tend to partly agree with your comments, but "replace repo > files" IMHO here is the principle of least astonishment/surprise. > http://en.wikipedia.org/wiki/Principle_of_least_astonishment Why is this? For years an update of *-release packages created .rpmnew files instead of overwriting the old ones.

>> In the fedora.repo file from F10, there is $basearch used in the URL of >> the gpgkey, maybe it is also possible to use $releasever there, so that >> it is possible to use the same gpgkey URL for several Fedora Releases, >> e.g. >> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-$release >> ver > Something like that is actually my plan -- ideally with a seperate > rpmfusion-{,non}free-keys package or something like that, as we can get > new keys out to the users of old releases without shipping a new > rpmfusion-{,non}free-release. How about using above URL in a new release of rpmfusion release and move the F10 key in to appropriate file and symlink the old path to the F11 key, e.g.: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora -> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-11 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-10 - F10 Key file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-11 - F11 Key This should not cause any problems for anyone. If rpmfusion-release is installed the first time, then it works for F10 and F11. If it is updated in F10, then the F10 Key is already in the rpm database. Therefore in case the repo config was changed and still contains the old URL for the gpgkey, it is still possible to update F10 packages and as soon as the system is changed to F11, yum will prompt the user to import the F11 key.

On Do Mai 14 2009, Thorsten Leemhuis wrote: > Hmmm, not completely sure yet, but that might work. Care to send a > patch? Ideally one that > * makes sure we don't need to do similar things for F12 and later This is my suggestion: http://till.fedorapeople.org/rpmfusion/ > * also makes the user aware that he has to merge the rpmnewfiles if he > still uses the hardcoded mirror list (e.g things like > > mirrorlist=http://download1.rpmfusion.org/free/fedora/.mirrorlist-free-fedo > ra-releases ). How about using a %post scriptlet that changes only this URL in *.repo files if they exist? This is not a very intrusive change and would be imho ok. Is there a list about which old URLs should be mapped to which new ones?

How about using a %post scriptlet that changes only this URL in *.repo files if they exist? This is not a very intrusive change and would be imho ok. Is there a list about which old URLs should be mapped to which new ones?