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-fe...
).
CU
knurd