RP> On Wed, 2007-10-24 at 13:25 -0800, Jeff Spaleta wrote:
>> Point of fact... is there anything which depends on firefox that is
>> currently experience a depchain problem that is considered a
>> mandatory application? Crap like yelp and devhelp and Miro are
>> fundamentally optional components. And you absolutely are not going
>> to be able to make a strong enough argument that firefox security
>> updates should be delay one milliseconds to keep optional packages
>> from breaking. It just isnt going to fly. People who do not have
>> these optional components installed will suffer lapses in security
>> unnecessarily.
>>>>> "RP" == Richi Plana writes:
RP> Well, whether yelp and devhelp are "crap" is debatable (I'm a
RP> software developer as well as a user and I've yet to find use for
RP> either.
"yelp" is not a "crap application", and *is* a fundamental part of the
GNOME desktop, and it is "mandatory" for the "GNOME Desktop
Environment" group, see the comps-f7.xml file:
<packagereq type="mandatory">yelp</packagereq>
This means that all Fedora users who install GNOME via pirut etc. or
in anaconda (which is probably the majority of users who leave
everything at the default in anaconda) *will* have yelp installed, so
this is not some obscure "leaf" application that the Firefox
maintainers should ignore.
RP> Don't get me wrong, though. I agree that security updates SHOULD
RP> NOT be delayed. But if they can't be applied, then they're
RP> effectively delayed. I'm just saying that for certain updates,
RP> the user should be given the choice to either force the update and
RP> allow it to break the dependency or do an automatic dependency
RP> resolution by REMOVING packages (as opposed to adding). I know
RP> it's complicated, but if it's worth it, then at least it can go on
RP> the table.
That's the way "smart" and "apt" package managers work, but I believe
that it's been considered by the yum maintainers as not to be
desirable.
RP> I've gone ahead and removed "yelp" and "devhelp", but removing
RP> dependent packages isn't always a choice.
Until the xulrunner solution is in place there basically needs to be
better communication from the firefox maintainer to the downstream
maintainers. At the very least an e-mail almost immediately after the
firefox update is pushed to each of the downstream dependent package
maintainers that the new firefox security update has been pushed and
please rebuild packages ASAP would be useful. (Apparently
telegraphing the change in advance to maintainers in advance of the
update is considered a security risk, which is debatable, but anyway).
The firefox maintainer(s) can use repoquery to get a list of all such
packages and be ready to send it immediately. (My apologies if this
was already done in this case.)
If the maintainer doesn't respond reasonably quickly, other
maintainers could be permitted to step up to the bat to rebuild
the broken apps against the new firefox themselves.
This would be preferable rather than let those maintainers (galeon,
Miro etc.) discover them through multiple bugs filed on bugzilla
and/or user forums or IRC several days later, dragging the updating
process on, and generating confusion) which seems to be what tends to
happen.
Alex
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
