-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhf6rQACgkQT2AHK6txfgybVgCgnJLGlwiqAc PrAcHiis17GLiC
uXYAnipBD/G53DYZN96pu/p0GOqsZQ1P
=YKAT
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

-----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

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.6.3 (Build 3017)
Charset: us-ascii

wj8DBQFIY+3dT2AHK6txfgwRAuaWAJ9Pm4T6mx8L0JlkNF0BE+ E1FzNgeQCg2VAm
dSZ5muo79Wzh6WbxuLIkr28=
=QhxX
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list