On Wed, 2010-11-24 at 20:10 -0500, Eric "Sparks" Christensen wrote:
* jjmcd to follow up on fedora-bookmarks updates
OK, when we talked about this at the meeting I didn't totally "get" what
the issue was, although in general, the pattern of my thinking really
didn't change much after I studied the SRPM.
Basically, we need to do something active during RPM install. This
looks like a pretty simple sed script could do it, the problem is I
don't know whether it is considered good form, and whether we need to
take some additional steps to warn the user what has happened.
Basically, here's the deal. fedora bookmarks installs an html file,
easy enough to replace. The problem is the html file gets read,
essentially copied, the first time the user runs Firefox (not sure about
all other browsers, Seamonkey seems to do the same as FF, but it doesn't
look like the others do. Arora, Dillo, Galeon, Kazehakase, Konqueror,
Midori and Mosaic all seem OK. Epiphany adds some Fedora-specific
bookmarks but none point to docs.fp.o.).
Now, the user may actually make changes to the copy, so for the update
to have any effect, we would need to change the user's copy, too. I'm
sure other apps update user configuration files. fedora-release-notes
will, in some circumstances, but in a very controlled, system managed
We couldn't just copy the new bookmarks to the user's copy since that
would write over any changes he made. However, editing the URLs would
be safe. It is a little bit of a challenge in that there is a randomly
named directory in the path, but I don't think that is likely to be a
I don't see anything in the RPM guidelines that says you CAN'T do this
sort of thing, but I have this nagging suspicion that it is
We talked about changing the redirects, but that breaks the Fedora 13
links. In hindsight, it was a mistake to make those redirects without
including the release in the URL, or at least, managing the situations
where those redirects are used. I suspect in most places, the redirect
gets used in places where someone wants to make a version-independent
reference, which I suspect is most of the time. It is just this one
case where we install something with a link that it is a problem not to
have the release number.
I think the answer may end up being to simply not fix the problem for
Fedora 14 (although just changing the source copy would fix it for new
users), but be sure we don't do this again for 15+.