On Sat, 28 Jun 2008 18:53:24 +0200
fedora(a)leemhuis.info (Thorsten Leemhuis) wrote:
On 26.06.2008 21:28, Jochen Schmitt wrote:
> On Tue, 24 Jun 2008 21:42:31 +0200, you wrote:
>> So in the end it's just choosing the least evil thing to do. Maybe
>> that's just keeping kyum in the repo; as the yum-ABI shouldn't
>> change it might be the least evil and easiest thing to do as long
>> as no security problem are found.
> [...]
> There are some bugs in the package, which will never been fixed.
That's life. We are just distributing things (or software, to be
precise). We do that at no cost and if the instance that creates the
thing we distribute(d) stops to maintain the thing then it's IMHO not
our task to clean everything up behind then. Just keeping it in the
repos IMHO is what we normally should do, as taking things away is
likely not something users like much.
Agreed.
> I can rebuild the package, if there may be any build
dependencies
> issues,
This is RHEL where something like that should not happen ;-)
> but there will be never get a version which is migrated to QT4.
Doesn't matter much ;-)
BTW, now that I'm thinking about it: *maybe* it might be nice to ship
a final update for EPEL kyum package that has something like this in
its description, summary and/or README.fedora:
{{{
Note: The kyum developers stopped working on kyum. EPEL will keep it
in its repos for the forseeable future and try its best to fix
security bugs as EPEL has users that have it installed and rely on
it. But we might drop kyum in case a big and hard to fix security
problem show up sooner or later. Future version of EPEL are unlikely
to ship kyum.
The best thus would be if you look out for alternatives to kyum and
uninstall kyum when you found one.
}}}
Perhaps. This is another case where it would be nice to have a
'epel-announce' type mailing list for end users to subscribe to.
Announcements there about things like this would be usefull I think.
Also, it would be good to add to a changelog entry about this, as many
admins check changelog entries to see what changed and what impact it
has.
anyhow, I agree with Thorsten... we should leave the package around for
current branches, and just not build it for new ones.
CU
knurd
kevin