RFC regarding rpmfusion-{non,}free-release and F11

[Thorsten Leemhuis]

On 14.05.2009 10:25, Till Maas wrote:
> 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. 

I didn't say otherwise in quoted para ;-)

> If you expect people that changed their repo config

I afaics didn't say that either -- I only said those that to big changes
that might break things if we ship the files as noreplace should be
careful.

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

Because it breaks for those that did small modifications and forget
about them -- hardcode a mirror, enable or disabling the repo using PK
(which might rpm detect the file as changed) and things like that.

>> 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.

* we didn't change the keys back then
* the files in the livna at least once, I think even two or more times
were also marked as %config without noreplace to make sure the users got
them
* we afaics from the download stats still have lots of users that use
the hardcoded mirrorlist files (that had been a temporary solution for a
few weeks only) instead of mirrormamager, as people didn't merge the
.rpmnewfiles
* even people that tested rawhide complained on IRC because they ran
into trouble as they were not even aware they had to merge rpmnew files

>>> 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.

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
* 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-fedora-releases
).

CU
knurd