-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo,
unfortunately, the upstream author has no time to maintain the kyum package.
So I have to retired this package in the Fedora collection.
If anyone wnat to resurrecting this package, they have to overtake the upstream project from sourceforge.net
Question: What I have to do to retiring this package in EPEL?
Best Regards:
Jochen Schmitt
On 23.06.2008 20:25, Jochen Schmitt wrote:
unfortunately, the upstream author has no time to maintain the kyum package.
So I have to retired this package in the Fedora collection.
If anyone wnat to resurrecting this package, they have to overtake the upstream project from sourceforge.net
Question: What I have to do to retiring this package in EPEL?
Normally Fedora's stance afaik is: a package that is shipped once is not ever removed from the repos as that creates trouble for the users -- for example if it's removed the package remains installed and user expects that it is still supported.
I'd really like to avoid removing packages from the repo, but maybe this is one of those rare cases where removing a package from the repo sooner or later *might* make sense. It would need to be discussed (which didn't happen in the past days, but that doesn't mean people don't care).
First thoughts in that direction: there needs to be a long warning period for users and the whole thing needs to be communicated clearly. Like for example:
- when RHEL 5.3 ships move package from stable to testing; users that still need it badly could get it there for a while - when RHEL 5.4 ships remove package completely from the repos - both these cases of course would need to be announced properly and loudly
But that doesn't solve the "package remains installed" problem. Some other package could obsolete it, but it's considered a bad thing by a lot of people (and they have a point in that!).
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.
Just my 2 cent.
Cu knurd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Thank you for your information.
I have retired this package, becouse the upstream author doesn't offer any support for this package anymore.
There are some bugs in the package, which will never been fixed.
I can rebuild the package, if there may be any build dependencies issues, but there will be never get a version which is migrated to QT4.
Best Regards:
Jochen Schmitt
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.
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. }}}
CU knurd
On Sat, 28 Jun 2008 18:53:24 +0200 fedora@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
epel-devel@lists.fedoraproject.org