Perhaps you can un-retire the package(s) and maintain them?
why should I fix things *you* broke?
If Eric didn't a) orphan the package in the first place, or b) remove the
package from the repository... why are you saying he broke it?
so, if he hasn't removed it himself but just asked someone else to remove
it, he has no responsibility for the removal?
All he did was say that these were orphaned packages which had other
problems attached to them.
"all"? - perhaps you've missed the quote from the ticket I posted just a
few lines above, which you've cut from the reply?
In the future, please follow this process instead:
1) Find out who removed the package.
Till
2) Find out why they removed the package.
because Eric asked epel-releng
... now I don't understand what are these two good for?
3) If the package was removed because it was orphaned, unmaintained,
if I get the docs right, this is not a reason to remove a package - there's
a difference between orphaning and retiring
or not responding to CVE's
that might be a reason - but in my opinion, the harm done by the removal is
in this concrete case (libmodplug, haven't examined the other cases) worse
than if we'd keep the vulnerable version ...
this is desktop software, no important servers will end up in flames
because of it; to compare, similar (stack corruption) issue exists in
libtiff version shipped in RHEL5 yet I'm not aware that Red Hat would be
planning to retire libtiff from RHEL5, while libtiff is by orders of
magnitude more important (`yum remove libtiff` would take away half of my
system, including e.g. java, cups or qemu ...)
find a packager who can do so that the package can go back into EPEL or
Fedora.
it shouldn't have gotten to the point when we talk about "go back"
the search should have been done *before* removing the package
there was no "ping, we're approaching this catastrophic scenario, isn't
there someone able to handle this before I file request for removal?" and
also I can't find any trace that it would consider also the dependent
packages, giving their maintainers a chance to step in or at least rebuild
before the removal, avoiding broken dependencies
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
